Methods and systems for transaction compliance monitoring

ABSTRACT

An automated transaction integrity monitoring system ( 100 ) operative to monitor electronic transactions of an enterprise and detect exceptions indicating noncompliance with enterprise policies. An extractor ( 140 ) obtains data from heterogeneous data sources such as enterprise databases. A staging database ( 155 ) caches data from the data sources. A mapper ( 150 ) maps enterprise data into an enterprise ontology used to express enterprise policies. A knowledge base ( 165 ) stores computer-executable policy statements, extractor data, and mapper data. A monitoring database ( 175 ) stores data mapped in the enterprise ontology. A collaborative reasoning engine (CORE) ( 160 ) executes policy statements against the monitoring database and determines exceptions. An exceptions database ( 185 ) stores exceptions from CORE. A case management system ( 190 ) provides for analysis and tracking of exceptions.

CROSS-REFERENCE TO RELATED APPLICATION

This application claims the benefit of and priority on U.S. PatentApplication No. 60/554,784, filed Mar. 19, 2004, entitled “METHODS ANDSYSTEMS FOR CONTINUOUS MONITORING OF TRANSACTION DATA FLOWS” by Peter H.Kennis, Stayton D. Addison, Charles A. Coombs, Andrew T. Otwell, andDaniel R. Kuokka, the disclosure of which is hereby incorporated hereinby reference in its entirety.

FIELD OF THE INVENTION

The present invention relates generally to compliance monitoring ofelectronic enterprise transactions, and more particularly relates totransaction-level integrity monitoring of electronic data transactionswithin enterprise computing systems for enterprise policy compliancemonitoring, anomaly detection, risk assessment, fraud deterrence, andinvestigation.

BACKGROUND

The growth of automated business systems, such as enterprise resourceplanning (ERP) and customer relationship management (CRM) applications,continues to propel productivity gains and new efficiencies in thee-business world. These business systems allow organizations to easilymanage accounts payable, human resources, account receivables,inventory, payroll, and more in real-time. However, automated businesssystems are subject to errors, misuse, and fraud, just like manual,unautomated systems. Furthermore, automated business systems can openthe door for business “hacks” resulting in asset misappropriation andsignificant financial losses. Both intentional and unintentionalproblems can jeopardize the integrity of transactions and reporting ofan enterprise.

Sources of integrity compromise can be broken into categories that rangefrom the most malicious to guiltless acts of well-meaning employees.Vulnerabilities in electronic transaction systems can: (1) permit accessto target business applications to launch fraudulent schemes, (2)unknowingly introduce system errors that affect asset appropriation,such as create duplicate payments, or (3) allow system control to beoverridden or circumvented, which then provides others the opportunityto abuse or misuse the system to commit fraud.

Organizations must take measures to reduce and eliminate all forms oferrors, misuse, and fraud. Present day financial controls of modernbusiness enterprises do not do enough to mitigate business risks fromfraud and error within the organization. According to reports from theAssociation of Certified Fraud Examiners (ACFE), fraud and white collarhacks collectively drain 6 percent of a typical business enterprise'sannual revenue. In 2002, these losses purportedly totaled over $600billion. A survey by one well-known accounting firm pegged the averageloss per company at greater than $2 million. Another accounting firmcalls the problem of fraud and error “a bigger loss problem than virusesand worms combined.”

The ACFE study found that an average fraud scheme lasted 18 monthsbefore it was detected. More than half of the detected schemes accountedfor losses greater than $100,000; nearly one in six caused lossesgreater than $1 million. The study also reported that nearly two-thirdsof all identified fraud was detected by “accident” or employee tips.

New motivations for evaluating financial controls, including theSarbanes-Oxley Act of 2002, have driven some enterprises to re-thinktheir financial controls. Section 404 of the Sarbanes-Oxley Act causedthe Securities and Exchange Commission (SEC) to establish rules aboutannual reports of certain companies, especially publicly held companies.Such rules require an annual report to contain (1) a statement ofmanagement's responsibility for establishing and maintaining an adequateinternal control structure and procedures for financial reporting, aswell as (2) management's assessment, as of the end of the company's mostrecent fiscal year, of the effectiveness of the company's internalcontrol structure and procedures for financial reporting. Section 404also requires the company's auditor to attest to, and report onmanagement's assessment of the effectiveness of the company's internalcontrols and procedures for financial reporting in accordance withstandards established by the Public Company Accounting Oversight Board.These requirements alone have triggered a search by both a company'smanagement and auditors for solutions to the establishment andmaintenance of internal control structures, which are inevitablyreflected in a company policies and procedures.

The Sarbanes-Oxley Act has heightened the importance of establishingenterprise policies regarding business activities and practices,ensuring compliance to those policies, and correcting lack of compliancepromptly and efficiently. Failure to establish and abide by somegovernment-imposed requirements can result in criminal as well as civilpenalties, so many businesses and other organizations are scrambling toestablish policies and compliance monitoring systems.

The real-time nature of information, analysis, decision-making, andpolicy validation creates additional complexities in financial controlsand compliance monitoring. Partly because so much information in modernbusiness enterprises is conducted by computer systems, some businessesand government organizations are exploring whether it is feasible toimplement automated transaction monitoring systems as an alternative orsupplemental to traditional people-based financial controls. In theprocess of exploring automated monitoring systems, many enterprises arefacing tradeoffs between stringent controls, operational efficiency, andbusiness risk. While stringent systems controls may stop a small percentof insiders who intend to defraud the enterprise, stringent controlsplace a heavy burden on the vast majority of insiders who are honest.Theoretically, automated transaction monitoring should allow anenterprise to remove many system restrictions and rely on real-timeanalysis to flag transactions that do not comply with enterprisepolicies. However, prior efforts to provide efficient and effectiveautomated transaction monitoring systems have not been entirelysuccessful.

Some prior approaches to automated transaction monitoring focused onnarrow fields of critical transaction data flows and were implemented todetect overt indications of profound and clear problems. Software toolsthat assist in recording and documenting the investigative actions of ahuman auditor are known (case management systems). Some functions inquerying available data were automated but only so under the directionof a human operator. Such limited approaches are watchful of only asmall percentage of transactions on a computer system. Problematicissues in areas outside of the monitored fields can be overlooked thoughsuch issues may result in problems in seemingly non-criticaltransactions, may affect critical transactions with subtlety, and mayresult in disperse adverse affects that amount in summations to problemsdeserving attention but that may go undetected.

Accordingly, there is room for improvement in automated transactionmonitoring systems that are operative for establishing enterprisepolicies and procedures, monitoring compliance with such policies andprocedures, and reporting violations or deviations from the establishedpolicies and procedures. But there are various requirements for a systemthat will be effective and acceptable to the business community.Automated transaction monitoring must rely upon sophisticated dataacquisition and multi-perspective analysis to correlate information fromERP systems, legacy mainframe applications, network monitoringsolutions, and external data sources. These various systems implementthe known business functions of accounts payable, accounts receivable,general ledger, human resources & payroll, and inventory management.After collecting relevant transaction information, automated transactionmonitoring solutions must analyze each transaction and the context ofthe transaction with the same level of scrutiny that an internal humanauditor and fraud examiner would employ. This complex analysis requiresa combination of domain engineering, automated link analysis, behavior,deductive analysis, and standard business intelligence.

Furthermore, an effective transaction analysis system should flagsuspicious activities and attempt to distinguish real concerns fromhundreds of indicators of fraud, misuse, and errors. The system shoulddetect acts of concealment and conversion designed to circumventstandard auditing techniques. The system should preferably operate incontinuous or near real-time mode, so as to detect efforts atconcealment and prevent complications and expense from later remedy.

Providing an acceptable transaction monitoring and analysis system hasproven a daunting task. Nonetheless, the benefits of such a system areclear: (1) transaction integrity monitoring should build an audit trailof transactions within a financial system and direct internal auditorsto the most suspicious transactions, (2) transaction integritymonitoring should establish a business environment that deters employeesand other insiders from breaking enterprise policies or defrauding thecompany, (3) transaction integrity monitoring should provide thebenefits of rigorous financial controls without the administrativeoverhead and bureaucratic burden, (4) even if compliance with policiesis not 100% or employees learn to game the system, risk managers shouldhave a solution that keeps pace with real-time business transactions,and (5) an acceptable transaction integrity monitoring system should actas the ultimate layer of security from outsiders who penetrate thenetwork as authorized users.

As will be described and explained in detail below, the presentinventors have constructed various systems and methods that meet theseand other requirements for an efficient, effective, robust, andcomprehensive automated electronic transaction integrity monitoring.

SUMMARY OF THE INVENTION

Briefly described, the present invention provides an automatedelectronic transaction integrity monitoring system that allowsestablishment, codification, and maintenance of enterprise policies,monitors electronic transactions of the enterprise from various andpossibly heterogeneous data sources, detects exceptions to establishedpolicies, reports such exceptions to authorized users such as managersand auditors, and provides a case management system for tracking suchexceptions and their underlying transactions. The disclosed systemreduces the cost of compliance with regulatory, contractual, andbusiness process compliance, including ongoing Sarbanes-Oxleycompliance, by continuously monitoring key controls including thatrequired for Section 404 certification by auditors. Use of systems andmethods constructed in accordance with the invention addresses thetangible costs of controls testing and remediation along with theopportunity costs associated with the internal distractions ofcompliance. Use of the present invention catches errors, fraud andinternal control issues early in the transaction process so thatcorrections can be made before time is wasted duplicating and reversingwork, before money is lost, and before controls are deemed deficient. Byidentifying the root causes of control violations and errors in realtime, the present invention allows an enterprise to improve the qualityof its earnings, ensure accountability, enhance business processes, andremediate any weaknesses for regulatory compliance.

To meet the heightened concerns about inside threats from systems-basedfraud, misuse, and errors, the present inventors pioneered the conceptand technologies of automated transaction integrity monitoring (“TIM”),according to systems and methods of the present invention. Unlikeexisting perimeter security solutions or access control systems, systemsconstructed in accordance with aspects of the inventions identifytransactions where authorized users perform suspicious or otherwisenoncompliant transactions within business systems. A TIM systemaccording to the invention(s) analyzes transactions across multiplebusiness applications to detects, prevents, and deters financial lossfrom systems-based fraud, misuse, and errors.

Embodiments of the present invention combine advanced data acquisition,data analytics, case management, and evidentiary analysis functionality.The disclosed systems and methods collect data across multiple platforms(including IT infrastructure as well as external data sources such aspublicly accessible databases), and perform multi-perspective analysisto identify fraud, misuse, and errors. The system is capable ofdetecting problem transactions in several ways, including the use ofmultiple indicators of problems, linkage to related entities, trackingongoing exceptions to policies that have not been resolved, and helpingidentify patterns that are associated with errors, misuse, and fraud.The system then generates high-impact reports, provides integrated casemanagement, and enables evidentiary analysis.

The benefits of such transaction integrity monitoring are clear. First,such transaction monitoring establishes a business environment thatdeters employees and other insiders from committing business hacks.Transaction integrity monitoring provides the benefits of rigorousinternal controls without the overhead. Even if procedural rules are not100 percent maintained or employees learn to game the system, riskmanagers will be satisfied with a solution that keeps pace withreal-time business transactions. Finally, transaction integritymonitoring acts as the ultimate layer of security from outsiders whopenetrate the network as authorized users.

The data extraction methodologies utilized in aspects of the inventionsemploy multi-pass and multi-system query technologies. The systemcollects data across multiple platforms to correlate information fromERP systems, legacy mainframe applications, network monitoringsolutions, and external data sources as relevant to many different typesof enterprise applications, such as (but not limited to) accountspayable, accounts receivable, general ledger, human resources andpayroll, customer relationship management (CRM), inventory management,email, electronic document storage and retention, and contractsmanagement.

A system constructed in accordance with aspects of the invention alsoprovides end-to-end case management and advanced investigative linkanalysis for high quality cases with irrefutable evidence. The casemanagement system supports the collection and management ofcase-specific exceptions, clues, interviews, e-mails, and reports, in asecure work area to which only authorized users and/or administratorshave access. This secure work area greatly increases an investigator'sability to quickly and thoroughly resolve multiple cases withoutsacrificing the legally required integrity of the process.

The advanced evidentiary analysis tools significantly reduce theinvestigative and forensics analysis workload. Complex link analysis ofthe case related subjects, systems, and accounts takes a fraction of thetime associated with manual research and analysis methods. Furthermore,use of the system can assist in the recovery of lost assets.

Preferably, systems constructed in accordance with the inventions aredesigned with security as an essential element of a hardened appliance.The cases management system provides a digitally secure and trusted“evidence locker” that stores transaction records, the reasoning behindevaluations and activities associated with the investigation process.Other security features provided in embodiments of the invention include(1) encryption and authentication of communication channels, (2)out-of-band configuration options to block its visibility on a network,(3) a hardened operating system, and (4) support for authenticatedexternal/supplemental queries into enterprise business systems andqueries to external data sources.

More particularly described, the invention(s) provide methods andsystems for the continuous monitoring of data corresponding totransactions that are computerized or that have related data recorded orprocessed on a computer, a system of computers, or a computer network.Data traffic from multiple and possibly heterogeneous sources iscontinuously and repeatedly monitored for policy exceptions that may beclues indicating attention or investigation is in order with regard toparticular transactions. Clues are potentially indicative of errors andomissions promulgated by mere operator mistakes, system malfunctions, orcomputer software failures. Furthermore, clues are potentiallyindicative of misuses and intentional or unintentional failures incompliance with policies. In the worst circumstances, clues areindicative of fraudulent activities.

In one aspect, the invention provides powerful data collectionfunctionalities and abstracts information about transactions to a humanuser. The disclosed system provides automated data collectioncapabilities for seamless collaboration between automated and humanselected searches. Heterogeneous data sources are utilized andcorrelation pre-processing sorts multi-level likelihoods of problemdetection to alert a human operator or trigger pre-selected actions suchas the assembling of detected events into case folders.

In another aspect, the invention provides data analysis capabilitiesusing incremental evidence gathering and heuristic and collaborativereasoning. Automated monitoring techniques include enterprise policyrule sets to continuously monitor a data source and periodically oroccasionally query a database for patterns indicative of non-compliantbehavior or fraud schemes.

In another aspect, the invention provides case management tools such asuser interface controls to empower an investigator with regard todirected queries and to provide implementation control with regard toautomated searches.

In another aspect, the invention provides compliance monitoring toprovide for synchronization between enterprise policies and operationalactivities. Process errors and inefficiencies are detected and trackedthrough human-managed automated monitoring and problem-patternrecognition.

In another aspect, audit compliance is ensured with internal controlsthat results in reduced asset loss, increased operational effectiveness,and increased corporate and shareholder confidence. Corporate governanceis enhanced while addressing regulatory requirements related toSarbanes-Oxley. Performance indices such as cumulated impact aredetermined and reported continuously or periodically.

A further aspect of the present invention solves a need in today'ssecurity marketplace by providing continuous controls monitoring of 100%of business transactions and also provides a solution for management todetermine that internal controls are operating effectively. Data isacquired in near real time and analyzed optionally in an independentsystem to assure the integrity of the data.

Another aspect of the invention provides methods and systems for acollaborative reasoning engine (CORE). The CORE is coupled to aknowledge base that stores computer-executable policy statements in theform of XML frames. These statements or frames are provided in sets,with an initial set of base frames that addresses many common enterprisecompliance policy scenarios. The base frames can be customized orsupplemented with custom frames to address the specific compliance needsof the particular enterprise. Because the frames are expressed in thereadily-understandable and modifiable XML, the system is robust,flexible, and permits ready and rapid adaptation to new compliancesituations.

The CORE is operative to apply a set of policy-expressing frames todetermine whether or not a particular transaction is deemed policynoncompliant. Through a combination of multi-system query andlink-analysis techniques, a determination is made regarding likelihoodof whether an event is indicative of fraud, errors, or misuse. Acts ofconcealment and conversion that are designed to circumvent standardauditing techniques are detected.

A further aspect of the present invention provides rapid continuousautomated overview of internal activity across critical businessfunctions. A variety of automated cross-platform data monitoring andcollection techniques are utilized and complimented by a hybrid ofanalytic support modules to audit activity within business applicationsand to detect inappropriate and suspicious insider threat activity.Various categories of “business-hacker” activities are addressed inreal-time. Non-compliant business activities recognized include but arenot limited to fraud and theft, misuse and abuse, errors and omissions,and inappropriate system and control overrides.

Yet another aspect of the present invention provides measures ofcompliance of business transactions with company internal controls.Corporate governance scorecards and reports are generated. Whentransactions are detected as out of compliance, multi-level or iterativequerying determines whether these transactions are errors, overrides, oractivities that require further investigation. Process efficiency,revenue recognition and enhancement toward the ability to meetSarbanes-Oxley requirements and any level of external or internalauditing requirements are provided.

From the foregoing, those skilled in the art will understand andappreciate that, with its transaction integrity monitoring, exceptiondetection, analysis engine, and case management aspects, a systemconstructed in accordance with aspects of the inventions identifiesfraud, misuse, and errors that directly affect the bottom line of anenterprise or the operations of an organization. The disclosed systemcombines the benefits of a systems auditor, fraud examiner, forensicsauditor, and an information security specialist that is on duty “24×7”to monitor the effectiveness of internal controls. With its advancedanalysis engine, the disclosed system identifies systems-based fraud,misuse, and errors in veritable real time. Rather than relying onperiodic audits that sample transaction data, the disclosed system'stransaction integrity monitoring identifies a problem the moment itoccurs and prevents a perpetrator from covering his or her tracks. Byidentifying errors, misuse, and abuse in veritable real time, thedisclosed system minimizes financial loss by allowing an organization toquickly and decisively respond. In many cases, use of the system allowsan enterprise to close a hole before it can be exploited. Finally, withtransaction integrity monitoring, the disclosed system empowersenterprises to “trust but verify” its financial transactions. The systemallows an enterprise's management team to establish a “tone at the top”regarding expectations of conduct within the organization.

These and other aspects, features, and benefits of the presentinvention(s) will become apparent from the following detailed writtendescription of the preferred embodiments taken in conjunction with thefollowing drawings, although variations and modifications therein may beaffected without departing from the spirit and scope of the novelconcepts of the disclosure.

BRIEF DESCRIPTION OF THE DRAWING FIGURES

FIG. 1 is an overview of an exemplary enterprise resource planningsystem (ERP) environment with transaction integrity monitoring (TIM)according to aspects of the present invention.

FIG. 2 is an overview of an integrated ERP system environment withtransaction integrity monitoring according to other aspects of thepresent invention.

FIG. 3 schematically illustrates exemplary aspects of a distributed ERPsystem environment.

FIG. 4 illustrates exemplary heterogeneous databases storing informationrelating to business transactions and exemplary support andtransactional entities.

FIG. 5 illustrates changes to exemplary monitoring entities withmetadata.

FIG. 6 is a flow chart of three major steps of TIM system: dataextraction, mapping, running CORE.

FIG. 7 is a portion of exemplary code for TIM system configuration.

FIG. 8 is a portion of exemplary code for a data extractor architecture.

FIG. 9 shows a portion of exemplary extractor file.

FIG. 10 is block diagram of multi-stage data extraction.

FIG. 11 illustrates how the TIM system identifies changes in a monitoreddatabase.

FIG. 12 shows an exemplary ERP system such as SAP where a programmaticextractor is employed.

FIG. 13 shows a portion of exemplary code for a programmatic extractor.

FIG. 14 shows a portion of exemplary code for a master extractor.

FIG. 15 shows a portion of exemplary code for a log extractor.

FIG. 16 illustrates an exemplary log file to provide information relatedto database updates.

FIG. 17 shows a portion of exemplary code for a resync extractor.

FIG. 18 shows an exemplary data extraction of a series of relatedbusiness transactions comprising support and transactional entities.

FIG. 19 is a block diagram of an exemplary mapper.

FIG. 20 shows a portion of exemplary code for a mapper.

FIG. 21 illustrates a source table in a source ERP database mapped ornormalized to a monitoring database target table with fewer fields andmetadata.

FIG. 22 shows a portion of exemplary mapper mapping file.

FIG. 23 shows a portion of exemplary ontology file.

FIG. 24 is a block diagram of a knowledge base.

FIG. 25 shows a portion of exemplary code for CORE execution.

FIG. 26 illustrates an exemplary policy exception of an invalid businesstransaction sequence.

FIG. 27 illustrates another exemplary policy exception of overriddentransactions and corresponding abbreviated exemplary transactionsrecorded in the monitoring database with metadata.

FIG. 28 illustrates exemplary policy exceptions created by a COREprocess after transactions are examined.

FIG. 29 illustrates a frame/executable policy statement expressed in XMLwith corresponding indicator and other aspects.

FIG. 30 shows an abbreviated frame with an expression to calculateconfidence level associated with a corresponding indicator.

FIG. 31 illustrates base frames, custom frames, and a run time sequenceof frames.

FIG. 32 shows a frame reflecting the relationship among confidence,impact, priority, and wariness.

FIG. 33 is a table to illustrate the data structure of an exception.

FIG. 34 shows the relationship of transactional entities, supportentities and exceptions caused by these entities.

FIG. 35 is an exemplary UI screen view of exceptions and relatedentities.

FIG. 36 is an exemplary UI screen view of related entities of anexception.

FIG. 37 is an exemplary UI screen view of an exception and its relatedentities.

FIG. 38 is an exemplary UI screen view of some related entities fromdifferent data sources.

FIG. 39 is an exemplary UI screen view of an exception discovered bylink analysis that relates information of a vendor in the AP databaseand an employee in the human resource database.

FIG. 40 is an exemplary UI screen view of exception case management withits summary information.

FIG. 41 is a portion of an exemplary UI view of entities showinginformation about an employee.

FIG. 42 is a portion of an exemplary UI view of an exemplary case with agraphical indicator of a chronology of one or more transactions andexceptions involved.

FIG. 43 is a portion of an exemplary UI view of a report generated bythe case management system showing cumulated impact of a collection ofrelated exceptions in a month.

FIG. 44 is a portion of an exemplary UI view of a report generated bythe case management system showing cumulated impact of a collection ofrelated exceptions having same status.

FIG. 45 is an exemplary UI screen view of assignment of an exception toan owner.

FIG. 46 is a portion of an exemplary UI view of notes associated with acase.

FIG. 47 is a portion of an exemplary UI view of logs of activitiesrelating to a case.

FIG. 48 illustrates the determination of an exemplary exception inresponse to changed data.

DETAILED DESCRIPTION

Prior to a detailed description of the invention(s), the followingdefinitions are provided as an aid to understanding the subject matterand terminology of aspects of the present invention(s), and notnecessarily limiting of the invention(s), which are expressed in theclaims. Whether or not a term is capitalized is not considereddefinitive or limiting of the meaning of a term. As used in thisdocument, a capitalized term shall have the same meaning as anuncapitalized term, unless the context of the usage specificallyindicates that a more restrictive meaning for the capitalized term isintended. A capitalized term within the glossary usually indicates thatthe capitalized term has a separate definition within the glossary.However, the capitalization or lack thereof within the remainder of thisdocument is not intended to be necessarily limiting unless the contextclearly indicates that such limitation is intended.

Definitions/Glossary

Actor: an individual responsible for conducting business activity withinan Enterprise, typically generating Business Transactions. Theactivities of Actors are monitored in accordance with the principles andoperations of the present invention.

Administrator: a type of user of a system made in accordance with theinvention that has special permissions or access to certainadministrative or configuration functions, e.g. a knowledge engineer,trained technician, system operator, or other person who works with anEnterprise. Typically, such a person assists in system configuration,creates Base Frames, and modifies/customizes Frames to create CustomFrames for use in the present invention.

A/P. Accounts Payable, a financial system function.

A/R: Accounts Receivable, a financial system function.

Application: a computer program that operates on a computer system,e.g., but not limited to, a computer program of an ERP, CRM, or HRsystem operated by or on behalf of an Enterprise. Further examplesinclude an accounts payable (A/P) program that is used by the Enterpriseto pay its vendors, employees, etc.; customer resource management (CRM)and other customer support programs, employee information applications,accounts receivable programs, inventory management programs, enterprisedata storage and management systems, email systems and servers, andvirtually any other type of program that generates transactions.

Base Frame: a Frame that is basic, or universal, or generally applicableto a wide range of circumstances for a variety of different Enterprises.For example, there is a strong correlation of fraud when an employee ofa company is listed as a vendor within the company's payables system; aBase Frame that determines if an employee identifies himself or herselfas a vendor for receiving payment is generally believed to be applicableto a wide variety of Enterprises. A set of Base Frames is preferablyprovided with an initial configuration in preferred embodiments of thepresent invention.

Business Transaction: a Transaction reflecting or representing businessactivity of an Enterprise, typically represented by one or more datafields of information stored in a database of the Enterprise, e.g. an HRor ERP type database. Generally, an Actor generates BusinessTransactions.

Case: A collection or repository of information representing one or moreExceptions and other related information, to facilitate investigations,monitoring, compliance tracking, etc. A Case is useful in collecting aChain of Evidence that might be useful in policy enforcement ordiscipline. Generally synonymous with Preliminary Inquiry orInvestigation, which may be considered different levels of a Case. Alsocan be referred to as a Case Folder.

CEV: comprehensive exception view, a user interface view of a particularexception including information related to this exception such asexception ID, description, priority, potential impact, owner, relatedentities, etc.

Chain of Evidence: a collection of related information that is or may beused to demonstrate that the current records match the claimed reality,i.e. proof that evidence has not been intentionally or unintentionallymodified or corrupted.

Changed Entity: An Entity that has changed, e.g. if data correspondingto a business transaction has been changed, such as the invoice numberof a Transactional Entity corresponding to a real invoice, the datarepresenting the change is a Changed Entity.

Clue: something that leads one toward the solution of a problem. A Cluecan be one or more Indicators or one or more Exceptions. Indicators andExceptions are species of Clue, but a Clue may consist of informationother than Indicators or Exceptions.

Collaborative Reasoning Engine or CORE: a component of a system ormethod in accordance with the invention that executes Frames inaccordance with the invention. Is a particular inventive species of aCompliance Rules Engine. Also Transaction Analysis Engine.

Compliance: the state of consistency and adherence to a policy, asreflected by one or more Frames.

Compliance Rules Engine: a system and/or software operative forexecuting one or more logical rules against a collection of data, todetermine whether there is a violation of data rules. This is ageneralized concept; see also Collaborative Rules Engine.

Compliance Policy Statement: an expression of a policy of an enterprise,typically in the form of a computer-executable series of statements andexpressions, expressed in a computer-executable language such as XMLframes. See also Frames.

Confidence: a function, generally mathematical in the present invention,of the quality and quantity of certain Indicators. In certain aspects ofthis invention, Confidence is a probability that an Exception or Caserepresents an actual impact or real-world event. Confidence can beexpress as a numerical value or a percentage; Confidence may be comparedto a threshold value in order to establish an Indicator or trigger anException. Confidence can also be expressed in cumulative or summaryterms such as high, medium or low.

CRM: customer relationship management; relates to aspects of interactionthat an enterprise has with its customers. Many aspects of CRM are nowcomputerized and generate various transactions, e.g. inquiries fromprospective new customers, contact management functions, customer listmaintenance, help desks and customer service representative monitoring,email organizers, web site interactivity, product returns and credits,couponing and rebates, online chat functions, instant messaging, etc.

Customer Control Objectives: narrative statements of the policies of anEnterprise with respect to some topic or management goal or objective.Such narrative statements may be represented by and maintained in adocument or table (e.g. a database table), provided by the Enterprise.Customer Control Objectives are expressed formalistically in Frames orCompliance Policy Statements.

Custom Frame: a Frame that is especially created or modified for aparticular Enterprise, to reflect circumstances or policies applicableto that particular Enterprise. A Custom Frame may be created bymodification of a Base Frame and run in lieu of a particular Base Framethat is not applicable to that Enterprise, or a Custom Frame may becreated from scratch.

DBMS: database management system.

Entity: something that has a separate and distinct existence orconceptual reality outside the present invention and a lifetime beyond asingle business transaction. As used most often in this document, anEntity is the representation of data in a document or other aspect of anenterprise's business processes. An Entity has two main species:Transactional Entity and Support Entity. See also Changed Entity. AnEntity can also be Static Entity or a Transient Entity. A TransactionalEntity can exist in a Monitored Database or in a Monitoring Database.

Enterprise: an organization or business entity that utilizes the presentinvention; such an Enterprise will usually have one or more computersystems running one or more Applications, for which compliancemonitoring in accordance with the invention is effected. An Enterprisecan be a business, a government agency, a person, or virtually any otherorganization that conducts business transactions reflective of itsbusiness activity.

Enterprise Database: a database associated with an Enterprise, typicallystoring Transactions, Business Transactions, etc.

ERP System: Enterprise Resource Planning system, generally the software,system, and/or Applications responsible for planning and tracking thefinancial, logistical and human operations of an Enterprise.

Estimated Impact: a mathematical term, Confidence * Potential Impact.

Exception: an indication and representation of data corresponding to apossible violation of an Enterprise Policy. An Exception can occur froma single incident or action, or a collection of incident or action. Inaccordance with aspects of the invention, one or more Exceptions occuror are triggered as the result of the settings or values of one or moreIndicators from the execution of one or more Frames, in response todetermination by the logic of a Frame that something has occurred thatis suspicious or noteworthy and might be indicative of a lack ofcompliance. There can be multiple related Exceptions corresponding to apolicy violation. There can also be an aggregate Exception (a SuperException) that itself consists of multiple Exceptions.

Exception Handling: the processing of one or more Exceptions. A User canflag or identify an Exception with a status such as detected, underreview, dismissed, or fixed. Also relates to the storage and processingof Exceptions within database or store of Exceptions, such as a Case.

Extraction or Extract: a process of retrieving selected information fromthe databases of an Enterprise.

Frame: a computer-executable logical representation of a rule or set ofrules, determined by a User (typically an Administrator type user)responsible for establishing compliance monitoring processes toimplement a Policy, as applied to data or information reflecting one ormore transactions or one or more data items of transactions. A specificimplementation of a Compliance Policy Statement. In the preferredembodiments, a Frame is represented by an XML frame, although othercomputer-implemented mechanisms may be utilized. Typically, a Frameincludes logic responsive to values of one or more Indicators togenerate Exceptions. See also Base Frame and Custom Frame.

Fraudster: a user of a system who uses the system to perpetrate a fraud.

HR: Human Resources. When referring to a system, typically means acomputer system or Application operative to maintain information aboutpersonnel within an organization (such as employees), for example,payroll information, health care insurance information, retirementbenefits information, etc.

Impact: see Potential Impact.

Indicator: a signal, variable, marker or pattern of data thatcorresponds to, represents information about, and/or constitutes acomponent of an Exception. Typically, one or more Indicators make up anException. In aspects of this invention, a Frame containscomputer-executable logic that processes data representing Indicatorsand generates Exceptions. An Indicator typically relates to a specificcontrol activity and is designed to represent a specific controlobjective or Policy of an Enterprise. An Indicator may be a cumulatedvalue, and can itself be determined from other Exceptions. An Indicatormay also be an individual transaction or set of transactions that whendetected and analyzed are indicative of misuse, abuse, or fraud, orother lack of compliance with a Policy.

Inquiry: see Preliminary Inquiry.

Investigation: an official and systematic process of determining thefacts surrounding one or more Exceptions. In accordance with aspects ofthe invention, an Investigation can be stored in and represented by aCase.

Knowledge Base: a collection of Frames representing the compliancepolicies of the Enterprise, e.g. Policy Frames, stored in a data storeor database. In accordance with aspects of the invention, a collectionof XML data files that comprises computer-executable Frames, as well asdata or tables associated with Extraction and with mapping of extracteddata into the Monitoring Database.

Linking: the notion of retrieving and processing a number of relatedEntities, such as Transactional Entities, to assist in a broader reviewof transactions associated with particular Subjects, Support Entities,etc. For example, if a particular transaction such as a payment to aparticular vendor is discovered to be duplicative of another, earlierpayment to the same vendor, linking would allow the retrieval of otherpayments to that vendor, or identification, retrieval, and display ofother payments authorized or initiated by the party that created theduplicate payment(s), or retrieval of other transactions such asinvoices or other documents related to that particular vendor.

Link Analysis: correlating different business transactions or exceptionsfor the purpose of discovering or demonstrating a pattern of activity.

Mapping: a process of correlating data items identified in one mannerwith data items identified in a different manner. For example, relatinga data item from an ERP database identified in that database asCUSTOMER_NAME with a data item in another database (such as theMonitoring Database) identified as VENDOR.OST.

Monitoring Database: a database or DBMS that stores a selected subset ofinformation derived from an Extraction of predetermined informationrelating to Transactions that are monitored in accordance with aspectsof the invention. Typically the Monitoring Database is maintainedseparately and independently of any database that stores Transactions orinformation relating thereto. Entries in this database are referred toas Monitoring Entities.

Monitoring Entity: an entity comprising a data item in a MonitoringDatabase, typically comprising a selected subset of information from aMonitored Database. Monitoring Entities can be Transactional Entities orSupport Entities.

Monitored Database: a database or DBMS that stores information relatingto Transactions that are to be monitored in accordance with aspects ofthe invention. Also called a Transactions database, or Enterprisedatabase, or Source database.

Monitored Entity: database entries or item in a Monitored Database; canbe a Transactional Entity or a Support Entity.

Normalize: a process of transforming data items expressed in a firstdata item naming schema (e.g. of an enterprise database) into data itemsexpressed in a different data item naming schema (e.g. associated with amonitoring database). May also involve combining one or more data itemsor fields in the first schema to a single data item or field in thesecond schema (or vice versa), reducing or expanding the characterscount of the data item or fields, changing the units, changing the datatype, etc. See also Mapping, Ontology. E.g. Data items may be normalizedby mapping them into a different naming and data storage schema, inaccordance with an ontology.

Ontology: A collection of data and/or metadata, somewhat like adictionary, that provides for creating relationships and/orinteroperability between things that have different names, e.g. a datafield in one database might have a field identifier CUSTOMER_NAME, whilethe same information in another database might have the field identifierPERSONNAME. An ontology would have a list of each item, CUSTOMER_NAMEand PERSONNAME, with pointers to each other, thereby defining therelationship. Used in Mapping. An ontology may be, but is notnecessarily, constructed with known ontology construction tools such asthe Resource Description Framework (RDF), which is a general frameworkoften used to describe a web site's metadata or the information aboutthe information on the site.

Policy: a statement reflecting or representing the manner in which anEnterprise is to abide by rules or guidelines of behavior, sequence ofoperations, protocols, requirements for information, regulations, laws,or other indicators of actions.

Policy Frame: a Frame expressing or indicative of a Policy. May beexpressed in XML, but can be expressed in other computer-executableform. In various aspects of the invention, it should be understood thatto some extent all Frames are Policy Frames. Also, a Compliance PolicyStatement.

Potential Impact: the potential loss (typically monetary) associatedwith an Exception or Case. Also referred to simply as Impact.

Preliminary Inquiry: a process of gathering information about one ormore Exceptions to determine if a formal Investigation is needed or tobe conducted.

Priority: the relative importance of an Exception or a Case. The defaultpriority for a detected Exception may be based on the Estimated Impact.May be represented as “High”, “Medium” or “Low”, with numerical values,or with alphabetical values.

Private Flag: an indicator or flag that an Exception or Case should notbe included in search results or summary reports unless specificallyrequested; provided for access control that is limited to authorizedUsers only.

Record: in database parlance, a single instance or data item, usuallyconsisting of one or more fields of information, each field typicallyhaving a field identifier identifying what the information in that fieldrepresents. An array of records is often referred to as a table.

Source Database: another term for Monitored Database.

Staging Database: a special database that receives data from anextraction operation and holds the data temporarily prior to a mappingoperation.

Subject: person(s) and/or system(s) associated with a particularException or Case managed by embodiments of the present invention. Istypically an Actor.

Super Exception: an aggregate Exception that comprises multipleExceptions, i.e. the logic of a Frame may be responsive to theoccurrence of one or more previously-generated Exceptions, possibly fromthe execution of other Frames.

Support Entity: an Entity that is persistent over a relatively longperiod of time. An Entity typically relating to an Actor and/or thesubject matter of a business activity, e.g. vendors, employees,customers, products, third party service providers, service personnel,etc. and their associated information are considered Support Entities.Support Entities typically are static entities that have a longerpersistence than Transactional Entities. Support Entity is sometimereferred as Static Entity, See also Transactional Entity.

Table: a particular collection of database records in a DBMS, havingpredetermined data fields. A typical relational DBMS may be viewed as aplurality of tables or grids of information, with each row in the tableor grid corresponding to a record, and each column of the tablecorresponding to a particular data field or data type. The term istypically used in the conventional DMBS sense.

Transaction: a set of system actions that result in a completed businessactivity. For example, a transaction includes the actions associatedwith adding or deleting a new vendor within an A/P system, or changingthe name of an existing vendor from one name to another, or creating apurchase order. A transaction can relate to a Support Entity or aTransactional Entity. See also Monitored Transaction.

Transaction Analysis Engine: another term for CORE.

Transactions Database: see Monitored Database; generally synonymoustherewith.

Transactional Entity: an Entity that has a relatively short lifecyclecompared to a Static Entity; an Entity relating to a transaction and itsassociated information, typically corresponding to activities of or in abusiness process, for example, purchase orders, vouchers, payments,shipping records, service requests, change orders, etc. and theirassociated information are considered Transactional Entities. Also caninclude other activity that is not strictly business-process related,e.g. information technology (IT) infrastructure information of atransactional nature such as is provided by computer, networking, andtelecommunications equipment such as firewalls, routers, intrusiondetection devices, user authentication systems, application servers, andother similar equipment. Is typically a Transient Entity. See alsoSupport Entity, Monitoring Entity.

User: an individual or other entity that accesses or uses a compliancemonitoring system constructed in accordance with aspects of theinvention. Typically, a user is an administrator who works for theenterprise, such as a policy Administrator or person who receivesreports indicative of Exceptions, Events, or other failures ofcompliance. Typically, a User is not an Actor or Subject or other personsubject to an Investigation.

UI: User Interface. Typically means a software Application with which aUser interacts for purposes of entering information, obtaininginformation, or causing functions of an associated system to execute.

Wariness: indicates a level of suspicion of an Exception or Entity. Canbuild up or accumulate as a function of Confidence, Potential Impact,and/or Priority, or of Indicators.

System Overview

The embodiments of the present invention are preferably implemented as aspecial purpose or general purpose computer including various computerhardware, as discussed in greater detail below. Embodiments within thescope of the present invention also include computer-readable media forcarrying or having computer-executable instructions or data structuresstored thereon. Such computer-readable media can be any available mediawhich can be accessed by a general purpose or special purpose computer.By way of example, and not limitation, such computer-readable media cancomprise physical storage media such as RAM, ROM, EEPROM, CD-ROM orother optical disk storage, magnetic disk storage or other magneticstorage devices, or any other medium which can be used to carry or storedesired program code means in the form of computer-executableinstructions or data structures and which can be accessed by a generalpurpose or special purpose computer.

When information is transferred or provided over a network or anothercommunications connection (either hardwired, wireless, or a combinationof hardwired or wireless) to a computer, the computer properly views theconnection as a computer-readable medium. Thus, any such a connection isproperly termed a computer-readable medium. Combinations of the aboveshould also be included within the scope of computer-readable media.Computer-executable instructions comprise, for example, instructions anddata which cause a general purpose computer, special purpose computer;or special purpose processing device to perform a certain function orgroup of functions.

Those skilled in the art will understand the features and aspects of asuitable computing environment in which aspects of the invention may beimplemented. Although not required, the inventions will be described inthe general context of computer-executable instructions, such as programmodules, being executed by computers in networked environments.Generally, program modules include routines, programs, objects,components, data structures, etc. that perform particular tasks orimplement particular abstract data types. Computer-executableinstructions, associated data structures, and program modules representexamples of the program code means for executing steps of the methodsdisclosed herein. The particular sequence of such executableinstructions or associated data structures represent examples ofcorresponding acts for implementing the functions described in suchsteps.

Those skilled in the art will also appreciate that the invention may bepracticed in network computing environments with many types of computersystem configurations, including personal computers, hand-held devices,multi-processor systems, microprocessor-based or programmable consumerelectronics, networked PCs, minicomputers, mainframe computers, and thelike. The invention may also be practiced in distributed computingenvironments where tasks are performed by local and remote processingdevices that are linked (either by hardwired links, wireless links, orby a combination of hardwired or wireless links) through acommunications network. In a distributed computing environment, programmodules may be located in both local and remote memory storage devices.

An exemplary system for implementing the inventions, which is notillustrated, includes a general purpose computing device in the form ofa conventional computer, including a processing unit, a system memory,and a system bus that couples various system components including thesystem memory to the processing unit. The computer will typicallyinclude one or more magnetic hard disk drives (also called “data stores”or “data storage” or other names) for reading from and writing to. Thedrives and their associated computer-readable media provide nonvolatilestorage of computer-executable instructions, data structures, programmodules and other data for the computer. Although the exemplaryenvironment described herein employs a magnetic hard disk, a removablemagnetic disk, removable optical disks, other types of computer readablemedia for storing data can be used, including magnetic cassettes, flashmemory cards, digital video disks, Bernoulli cartridges, RAMs, ROMs, andthe like.

Computer program code that implements most of the functionalitydescribed herein typically comprises one or more program modules may bestored on the hard disk or other storage medium. This program code, asit known to those skilled in the art, usually includes an operatingsystem, one or more application programs, other program modules, andprogram data. A user may enter commands and information into thecomputer through keyboard, pointing device, or other input devices (notshown), such as a microphone, joy stick, game pad, satellite dish,scanner, or the like. These and other input devices are often connectedto the processing unit through known electrical, optical, or wirelessconnections.

The main computer that effects many aspects of the inventions willtypically operate in a networked environment using logical connectionsto one or more remote computers or data sources, which are describedfurther below. Remote computers may be another personal computer, aserver, a router, a network PC, a peer device or other common networknode, and typically include many or all of the elements described aboverelative to the main computer system in which the inventions areembodied. The logical connections between computers include a local areanetwork (LAN) and a wide area network (WAN) that are presented here byway of example and not limitation. Such networking environments arecommonplace in office-wide or enterprise-wide computer networks,intranets and the Internet.

When used in a LAN networking environment, the main computer systemimplementing aspects of the invention is connected to the local networkthrough a network interface or adapter. When used in a WAN networkingenvironment, the computer may include a modem, a wireless link, or othermeans for establishing communications over the wide area network, suchas the Internet. In a networked environment, program modules depictedrelative to the computer, or portions thereof, may be stored in a remotememory storage device. It will be appreciated that the networkconnections described or shown are exemplary and other means ofestablishing communications over wide area networks or the Internet maybe used.

Referring now to the drawings, in which like numerals indicate likeelements or steps throughout the several drawing figures, FIG. 1illustrates an exemplary enterprise computing environment 10 in which atransaction integrity monitoring (TIM) system 100, constructed andoperated in accordance with aspects of the present inventions, isoperative and useful for the purposes described herein. The enterprisecomputing environment includes an enterprise resource planning (ERP)system 110 as exemplary of a type of computer system with which theinventions are operative, although other types of computer systems arealso operative, e.g. enterprise email systems, contract managementsystems, customer relationship management (CRM) systems, documentretention systems, inventory management systems, etc. Collectively, suchvarious types of computer system are generally referred to as “ERP”systems in a broader sense for purposes of explaining and illustratingthe inventions.

Briefly summarized, the TIM system 100 is connected forcomputer-to-computer communications with an enterprise resource planning(ERP) system 110 which in turn is connected to and stores data in one ormore data sources such as ERP database systems 120, e.g. databases 121a, 121 b, . . . 121 n. Users 101 of the TIM system interact with thesystem via a user interface (UI) comprising a personal computer orterminal and associated display for configuring the system, constructingand maintaining the information such as policy statements, ontologymappings, extraction requirements, etc. (collectively referred to as“knowledge maintenance”), and receiving analysis and reports in a mannerthat will be described later.

ERP systems 110 with which the embodiments of the present invention areoperative include both disparate heterogeneous and stand alone computersystems that run individual ERP applications on behalf of an enterprise,such as account payables systems, human resources systems, accountsreceivable, general ledger, inventory management, and like. However, itwill be understood that integrated ERP applications (see FIG. 2) thatprovide these functions in an integrated environment in a singlecomputer system are also operative with the invention. Thus, it shouldbe understood in FIG. 1 that various applications, e.g., 114 a, 114 b, .. . 114 n, labeled as ERP-1, ERP-2, . . . ERP-n, are typicallyindependent applications that generate their own electronic datatransactions, and that such electronic transactions are stored in one ormore ERP databases, e.g., ERP database 121 a, 121 b, . . . 121 n. Forexample, and not by way of limitation, ERP database (DB) 1 may be anaccounts payable database that includes information concerning vendorsof the enterprise, payments to such vendors, the status of invoices andvouchers from vendors, etc. A second ERP database 121 b may relate tohuman resources (HR) functions and store information concerningemployees, their ID and/or social security numbers, their addresses,payroll information and deductions, insurance and benefits information,etc. Likewise, a separate ERP application 114 n can include contractsmanagement, accounts receivable, customer relationship management (CRM),email, or virtually any other type of computer system. In accordancewith aspects of the invention, virtually any type of computer program orsystem that generates, transmits, records, processes, or otherwisemanifests transactions, as the term is used herein, can be connected toand utilized with the present invention.

Data generated from enterprise transactions is stored in ERP databasesystem 120, such as databases 121 a, 121 b, . . . 121 n. Such databasesare considered monitored databases in accordance with aspects of theinvention. Transactions generated by the various applications in the ERPsystem 110 are stored in these databases, and information from suchdatabases is extracted, processed, and analyzed in accordance withaspects of the invention. Information stored in the monitored databases120 is considered monitored entities, which can take the form of supportentities or transactional entities, as defined herein. As describedelsewhere herein, support entities are typically static entities thathave a relatively long persistence within an enterprise such as employeenames, customer identification, vendor name, etc. Transactionalentities, on the other hand, are typically transient entities that existin a plurality relative to one or more support entities, e.g. a vendorof an enterprise may generate numerous invoices and receive numerouspayments over a period of time.

It should be understood that electronic transaction can be considered atransactional entity and processed in accordance with the invention, andconsidered as a part of assessing policy compliance. For example, thecreation of a vendor in an accounts payable system is a transaction, asis creation of a new employee in an HR system; both of these becomesupport entities after their transaction is completed.

In accordance with aspects of the inventions, monitored entities areextracted from the monitored databases 120 and processed in accordancewith the inventions as will be described. Such monitoring entitiescorrespond to transactions generated within a data source such as ERPsystem 110. Transactions within an ERP system 110 are created and/orhandled by an actor 102, such as an employee, executive, consultant,other authorized individual, or other person that interacts with the ERPsystem via a computer terminal such as that shown at 111. In accordancewith the aspects of the inventions, an actor 102 who is responsible fora transaction within the system 110 but violates policies—and therebyconstitute exceptions in accordance with the techniques describedherein—may become a subject of an investigation. As will be discussed ingreater detail, transactions associated with various actors, orsubjects, may be cumulated and viewed in accordance with aspects of thecase management features as described herein. For example, if aparticular actor 102 works in an enterprise's accounts payable functionand operates an A/P program module such as 114 a, he or she may generateone or more payments to various vendors, e.g., vendor 1, vendor 2, etc.Under certain circumstances, rules reflective of enterprise policy canbe constructed to determine if improprieties occur in the identificationof vendors, or providing unauthorized or excessive payments to vendors,or changing a vendor name to a different entity and changing it back,and other known fraudulent schemes.

Still referring to FIG. 1, a TIM system 100 that is constructed andoperative in accordance with aspects of the inventions described hereincomprises several major components. These include extractor 140, stagingdatabase 155, mapper 150, knowledge base 165, monitoring database 175,collaborative reasoning engine (CORE) 160, knowledge maintenance andadministration subsystem 170, and a case management system 190comprising an exceptions database 185 and analysis and reporting engine180. These components are typically provided in the form of one or morecomputer program modules that are stored and run on one or moreserver-based type computer systems comprising the entire TIM system 100,including storage devices such as disk drives and/or RAID arrays and/orstorage area network (SAN) devices to serve as the databases.Preferably, the entire TIM system 100 is provided with and runs on ahardened computer operating system, in a secure environment, physicallyseparate from the ERP systems 110 and databases 120 that are monitored,so as to provide out-of-band, secure, and controlled access operation.

An extractor 140 is operative to interface with the various data sourcessuch as monitored databases 120 and retrieve, be provided, or otherwiseobtain data from such data sources and monitored databases. Extracteddata from extractor 140 is stored in a staging database 155, whichtemporarily stores data so that the TIM system can operate out of bandwith respect to enterprise applications and thereby minimize performancedegradation of the monitored ERP systems. The extractor is responsive toand/or configured by extraction data (stored as extraction files aknowledge base 165) to determine an appropriate extraction methodologyfor a particular type of ERP database from which data is extracted andmonitored.

The extractor 140 comprises several subcomponents 141. A programmaticextractor 141 a is operative to provide information from an ERP system(such as provided by the known ERP system provider SAP, located inWalldorf, Germany), that provides or exports data automatically ratherby extraction. A master extractor 141 b is operative for an initial dataload to extract an entire predetermined data set, typically a limitedset (subset) of information or “snapshot” of data within an enterpriseat a predetermined point in time, and to store that initial and “master”data set in the staging database 155 or in the monitoring database 175.A resync extractor 141 c is operative to synchronize data in themonitoring database 175 to a master set of information in the monitoreddatabases 120 so as to minimize the likelihood that a lack ofsynchronization between data sets will create issues. A log extractor141 d is responsive to the provision of audit data logs by certain typesof ERP database systems, in the form of records indicating the additionor change of records within particular ERP data. An environmental sourceextractor 141 e is operative to obtain data from an enterprise'senvironment 133 (e.g. internal systems such as its informationtechnology (IT) infrastructure). Finally, an external source extractor141 f is operative to access and retrieve information from external datasources 132 via an external network 131 such as the Internet. As will bedescribed in greater detail, access to information in external datastores such as proprietary databases, publicly accessible databases, andthe like that may be required in enterprise policies to provide certainintegrity checks.

The environmental source extractor 141 e and external source extractor141 f obtain data from additional data sources 130. Such additionalsources are typically supplemental and additional to primary sources oftransaction data such as ERP systems. In accordance with an aspect ofthe invention, these additional data sources include the environmentalsources 133 and external data sources 132. The environmental datasources, such as the enterprise IT infrastructure, can include devicessuch as server logs 134, intrusion detection systems (IDS) 135,firewalls 136, and routers 137, as well as telephone systems, caller IDlogs, physical security access devices, and other types of devices (notshown) that generate electronic information indicative of use oractivity.

A mapper 150 is operative to retrieve data from the staging database 155and normalize, transform or map that information into a predetermineformat to comprise monitoring entities, which are then stored in amonitoring database 175. The monitoring database 175 stores monitoringentities, both support and transactional, identified by table and fieldnames in accordance with mapping data stored in a knowledge base 165.The mapping data (e.g. in the form of mapping files and ontology files)establishes relationships between monitoring entities stored in themonitoring database and monitored entities from the ERP databases. Aprincipal function of the mapper 150 is to transform data from variousand disparate (and possibly heterogenous) data sources into a sharedschema or ontology, so that an analysis engine can examine and correlatedata across the disparate systems and facilitate the preparation ofpolicy statements that consider information from different data sources.

A knowledge base 165 stores information required by the extractor 140(extraction data in the form of extractor files), information requiredby the mapper 150 (mapping data in the form of mapping files andontology files), and a plurality of computer-executable policystatements or frames 167 that constitutes the rules and/or logic fordetermining exceptions. A collaborative rules engine (CORE) 160, alsocalled a transaction analysis engine, is operative in accordance withaspects of the invention to execute policy statements, which constitutesone or more logical rules and/or expressions, against the monitoringdatabase 175 to determine whether there is a violation of policies orrules (i.e. exceptions), in a manner that will be described in greaterdetail below. Output from the CORE 160 in the form of exceptionsresulting from execution of frames 167 is stored as one or moreexceptions in an exceptions database 185. These exceptions, as will bedescribed, constitute indications of violations of enterprise policythat are reflected by and maintained in the frames 167.

By “computer executable policy statement,” it is generally meant thatthe policy statements are expressed in a computer-readable form, such asan XML frame containing data, commands, and logical expressions thatresolve to an outcome such as an exception, etc. Typically a policystatement can be “executed” in the sense that an interpreter can parsethe file and determine what computer-operations should be effected. Thepolicy statement is therefore a form of computer program or data for usein a computer program. A number of equivalents to the XML expressionwill be apparent to those skilled in the art, for example, a computerprogram in a conventional programming language such as C++, varioustypes of data structures, scripting languages, object modules, rulesstatements, and other forms of expression that can be interpreted andexecuted by a computer.

An analysis & reporting server 180 provides a user interface (UI) tousers, e.g., users 101, for purposes of receiving reports regardingexceptions and implications thereof, as well as providing a userinterface to a case management component 190 also as will be describedin greater detail below. Users 101 can be of different types, havingdifferent authorizations for different purposes. For example, certainusers such as user 101 a may have access to receive reports and managecertain cases or learn of certain exceptions, while another user 101 bmay be considered an administrator, with authorizations to set up otherusers, access and edit enterprise policy statements (or enter theminitially), configure the mapping data and extraction data, etc.

The foregoing discussion of FIG. 1 has illustrated a typical environmentwithin which the inventions herein are useful, in the context of an ERPenvironment where the enterprise provides different computing functions,perhaps via different computing systems or platforms in a distributedenvironment, each running individual applications for carrying out thefunction. For example, one server in an enterprise may run an A/Papplication, while another server, perhaps in a different physicallocation, may run an HR application, while yet another server, alsoperhaps in a different but perhaps the same physical location, may run acontracts management application or CRM system. The present inventionsare not limited to distributed environments, as will next be explained.

FIG. 2 illustrates a different (integrated) enterprise environment 10′with which the TIM system 100 is also operative. The known SAP system isan example of such an integrated ERP system. In such integratedenvironments, an ERP system 210 may consist of an integrated suite ofdifferent applications that provide enterprise functions such asaccounts payable, accounts receivable, human resources, etc., by way ofone or more application layers such as 221 a, 221 b, . . . 221 n runningon one or more servers that comprise the integrated computingenvironment. Such applications may execute by way of individualnetwork-connected computer systems such as 211 a, 211 b, . . . 211 n,accessed by enterprise personnel (actors) 102 who are responsible forgenerating transactions. In such an integrated environment, the variousapplication layers 221 generate and store data in an integrated ERPdatabase 121′, which maintains separate data files and/or tables for thevarious functions within the system 210, e.g., a vendor table, employeetable, products table, and various other database tables that aremaintained within the operation of a modern enterprise.

As in a more distributed, disparate, heterogeneous environment like thatof FIG. 1, an integrated environment as in FIG. 2 may derive additionaldata from additional data sources 130 for use in policy determinationand analysis, e.g. data from external data sources 132 that are externaland independent of the enterprise, or from sources that are associatedwith or internal to the enterprise such as the IT environment 133.

Those skilled in the art will understand and appreciate that the aspectsof the present invention described herein that are shown in FIG. 1 withrespect to a distributed enterprise computing environment are equallyapplicable to an integrated environment such as shown in FIG. 2. Such anintegrated ERP environment may not be strictly considered a distributedheterogeneous type system, but more integrated, but the information andthe table structures within an integrated environment nonethelesspossesses certain heterogeneous properties that are addressed andhandled by aspects of the present invention(s). Even in an integratedenvironment, information in different tables may contain relatedinformation that is utilized in implementing enterprise policy. Forexample, vendor information tables may not map directly to informationin employee tables or product tables, etc. Even more specifically by wayof example, an enterprise may have a policy that an employee cannot alsobe a vendor without supervisory authority. In accordance with such apolicy, if an employee is found to have the same address and telephonenumber as a vendor, the enterprise may wish to have an exceptionindicated and brought to the attention of appropriate personnel.

From the foregoing, it will be appreciated that the principles of thepresent invention are applicable in both distributed and integratedenvironments, in that monitored entities are extracted and mapped toconstitute one or more monitoring entities stored in the monitoringdatabase as described herein, so as to allow the detection of exceptionsthat not in compliance with policies or procedures of the enterprise.

FIG. 3 illustrates another exemplary enterprise computing environment10″ wherein a TIM system 100 constructed in accordance with aspects ofthe inventions is operative—a distributed environment. In such adistributed environment 10″, a plurality of ERP systems 301 such asshown at 301 a, 301 b, 301 c, 301 d are provided to implement thevarious enterprise functions such as accounts payable, human resources,accounts receivable, etc. These various systems 301 need not bephysically located in the same location and can be widespread anddispersed. The ERP systems 301 can be connected to the TIM system 100 byvarious communication means and methodologies, for example, viadedicated communication line or link 125 a, a wide area network (WAN)125 b, a local area network (LAN) 125 c, or the Internet 125 d.

Certain functions of the present invention may be dispersed andseparated, and need not be in the same physical location. For example,the extractor 140 and mapper 150 may be dispersed and located at variousremote sites and in different configurations. Specifically for example,the extractor 140 a and mapper 150 a in connection with ERP 1 can bephysically located at the ERP site 301 a, instead of locally proximateto the TIM system 100. Similarly, the extractor and mapper for an ERPsystem 301 b can be located within or proximate to the TIM system 100,such as shown at 140 b, 150 b. Likewise, the functions of extraction andmapping can be separated by locating the extractor 140 c at a remote ERPsite 301 c, with the mapper 150 c located proximate to the TIM system100. Those skilled in the art will understand and appreciate that theseprinciple functions of extraction and mapping are readily dispersible,for convenience, and need not be physically located at or near the othercomponents of the TIM system.

Transactional Entities

FIG. 4 illustrates exemplary heterogeneous databases storing informationrelating to electronic transactions of an enterprise, in the exemplaryform of business transactions, with which aspects and embodiments of thepresent inventions are operative. As will be shown, the presentinvention(s) are suitable for use in connection with many differenttypes of enterprise computing environments wherein informationcorresponding to transactions and entities involved in transactions isto be monitored for purposes of implementing enterprise policies,expressed in the ontology of the enterprise. In this regard, FIG. 4illustrates the notion of exemplary entities and transactions, both of asupport variety and of the transactional variety.

It will be understood from the outset that the examples shown in FIG. 4are meant to be exemplary and not limiting to the specific types ofdata, tables, entities, and the like. In accordance with the aspects ofthe invention, ERP applications 114 a, 114 b for ERP1, ERP2 withassociated databases 121 a, 121 b are configured to have data extractedtherefrom (or to provide data) that is analyzed in accordance with theprinciples of this invention. As will be known to those skilled in theart, information in databases is typically stored in one or more datastructures or tables, e.g. tables 402, 404. A typical database tablecomprises a plurality of data records 410, usually a plurality ofinstances of similar data items. A specific example of FIG. 4 is a firstenterprise computing system ERP 1 for accounts payable, with datacorresponding to vendors of the enterprise and invoices associated withsuch vendors, and a second enterprise computing system ERP 2 for a humanresource function, with data corresponding to employees.

In this example, the first enterprise computing system ERP 1 has adatabase 121 a storing a data structure or table 402 representing anexemplary vendor table for a typical A/P system, having a plurality ofdata records 410 a, each record having columns or field identifiers suchas name, address, vendor ID, bank account number, contact, etc. In manyERP systems, a vendor would be considered a relatively static entity,because vendor information tends to persist over an extended period oftime.

The second and different enterprise computing system ERP2 has anassociated database 121 b relates to the human resources function, whichstores a data structure or table 404 comprising of a plurality of datarecords 410 b that identify employees of the enterprise. Each record ofsuch an employee table 404 has field identifiers such as name, address,bank account number, social security number (SSN), and other relatedinformation. Typically, employees are also considered static entities,because data records associated with employees tend to persist withinthe records of the organization over an extended period of time.

The example of FIG. 4 also illustrates a different and more transiententity, namely, invoices of various vendors of the enterprise. Thedatabase 121 a of ERP 1 also stores an invoices table 406, whichcomprises a plurality of data records, each record relating to a singleinvoice. The invoices table 406 provides a function of tracking invoicesfrom vendors and whether such invoices had been paid. The exemplaryinvoices table 406 in FIG. 4 consists of a plurality of data records 410c, each record having fields identified as vendor ID, invoice number,amount, status, and other information related to invoices and payments.

Invoices are an example of transactions that are transient entities, asthe term in understood in the present invention, because such entitiestypically tend to exist in greater numbers relative to static entities,are related to one or more particular static or support entities, andthere tend to be a plurality of such entities respect to a single staticentity, e.g. a single vendor may have issued multiple invoices to theenterprise over a predetermined period of time.

It will be understand that the present invention is operative with bothstatic and/or support entities, as well as transient and/ortransactional entities, in that different instances or versions of eachof these entities may exist over time. In accordance with the inventionand as shown by way of example in FIG. 4, the disclosed TIM system 100is operative to extract information relating to monitored entities suchas vendors, employees, invoices, etc. from the various monitoreddatabases 121 of the enterprise computing systems, generate a reducedsubset of such information, and store such a reduced subset in themonitoring database 175 as monitoring entities.

Either static or transient entities, but especially static entities, canexist over time as different versions of the same conceptual entity.Conceptually, a particular vendor is always the same person, but thatvendor's name may change, its address may change, its bank account maychange, its telephone number may change, but the conceptual entityremains the same. Over time, the data representing this entity maychange. Some ERP systems do not provide for robust version changetracking, or provide adequate controls or supervision over changes toentities. Unauthorized or hidden changes to information about staticentities is known as a classic pattern of fraud for many organizationsand enterprises, and a typical subject for an enterprise policy thatdetects certain types of changes to static entities, or requiressupervisory permission and an auditable record.

It will be understood that the creation of any entity, whether static ortransient, is the creation of a transactional entity. Creation of avendor or new employee (both relatively static entities) involves atransaction that is initially a transactional entity (the data involvedin the creation); that entity may later be considered a support entity.Issuance of an invoice or purchase order involves a transaction that isa transactional entity. A change to a vendor or employee also involves atransaction that is a transactional entity, as does a change to aninvoice or payment. Any entity becomes a support entity and can bereferred to or utilized in policy statements.

For example, an entity such as a vendor can originally be created with afirst address, thereafter changed to a different address at a laterpoint in time, and thereafter changed again to provide a different bankaccount number for receiving payments, and thereafter changed yet againto undergo a name change from a corporation to an LLC. Throughout suchchanges, of which three have been given as an example, the basic entityremains conceptually, logically, and legally the same, yet certaininformation relating to the entity was changed over time.

Similarly with respect to transactional entities such as invoices, aninvoice will typically have a predetermined and fixed invoice number,but could have different and changeable information such as date,amount, items identified, and the like.

In accordance with aspects of the inventions, the state of a givenentity is captured in an initial or master extraction so as to providean initial data set representative of data in the enterprise at aninitial point in time (e.g. a snapshot). Thereafter, each change to acertain entities, whether static entities or transient entities, asrequired by enterprise policy statements, is captured by operation ofthe invention and stored as monitoring entities in the monitoringdatabase and analyzed in accordance with policies of the enterprise, asexpressed in the policy statements that execute on the monitoringdatabase, for purposes of detecting exceptions in the form of anomalies,duplications, duplicate payments, violations of company policy, and thelike.

Still referring to FIG. 4, in accordance with aspects of the invention,a reduced subset of information relating to monitored entities extractedfrom the monitored databases 121 is initially obtained during a masteror initial extraction or data load, by operation of the master extractor141 b (FIG. 1). In the example of information from the vendor table 402,the master extractor obtains a plurality of data records relating toselected information from the vendor table 402, reduced to provide alimited set of fields of information in accordance with the enterpriseontology, which are then mapped according to the enterprise ontology.This initial and master extraction comprises a collection of datarecords at a point in time t1 of the master extraction. This isdiagrammatically represented as the table 420, showing a plurality ofentities represented as vendor 1 at time t1, vendor 2 at time t1, . . .vendor n at time t1. It will understood that a master extractiontypically comprises a replication of at least portions of the vendortable 402, extracted and temporarily stored in the staging database 155,prior to reduction and mapping into the monitoring entities by operationof the mapper 150. The reduced subset of information, mapped inaccordance with field names and other parameters corresponding to thesystem ontology, is then stored as a plurality of monitoring entities inthe monitoring database 175.

Subsequent extractions of information from a table in a monitoreddatabase, for example, the vendor table 402, is represented at differentpoints in time by different data entries and stored in the monitoringdatabase 175, for example in a vendor table 430 that representsdifferent versions of the same entity (Vendor 1) at different points intime. Considering the example of the modified vendor discussed above,which occurred at different points in time t1, t2, t3, etc., thesubsequent extraction comprises a plurality of records relating tovendor 1 at different points in time. For example, the change to theaddress of vendor 1 subsequent to the master extraction at time t2appears as a separate entry in the monitoring database, and the changein bank account number of vendor 1 that occurred at time t3 is yetanother entry in the monitoring database 175. It will thus be understoodand appreciated that operation of the present invention allows thecapture of the state and/or status and/or versions of a particularentity, such as particular vendor, as it might exist in various pointsin time during the life of that entity. Operation of the policystatements against the various entities at different points in timeallows the comparison of fields of information for different “versions”of the same entity, which thereby facilitates the determination ofimproper actions with respect to particular entities.

Although the foregoing example of a vendor change is described inconnection with a static entity such as a vendor and a vendor table, itwill be understood and appreciated that the same principles apply tomore transient transactional entities such as invoices, checks,vouchers, insurance claims, refunds, returns, and virtually any othertype of transaction maintained within the data processing systems of anenterprise.

In accordance with aspects of the invention, transactional entities thatoriginate within enterprise systems (such as vendors, invoices, etc.)have a virtual counterpart as transactional entities in the monitoringdatabase. For example, support entities such as vendors in source table402 are mapped into a corresponding table(s) such as vendor table(s)420, 430 in the monitoring database 175, and entities such as invoicesin source table 406 are mapped into a corresponding table such asinvoice table 440 in the monitoring database 175.

Exemplary Static Entity: Changes & Metadata

With the foregoing principles relating to changes to static entitiesover time, turn next to FIG. 5 for an explanation of an exemplarysequence of transactions relating to changes to an exemplary staticentity, namely, that of a typical vendor. The example in this figureillustrates a number of individual transactions relating to a particularvendor (Widget Company) that has undergone changes to selectedinformation, for example, address and bank account identifier. Eachchange to the information associated with the vendor is captured byoperation of the disclosed TIM system 100 and comprises a changedentity. Each change comprises a separate transaction 501, 502, 503, 504,505. Each transaction is stored in the monitoring database 175, withversioning information that allows determination of the changes thathave occurred over time and who made such changes.

In the example of FIG. 5, the entity being monitored is vendor WidgetCo., which is identified in each transaction 501-505 by a vendor IDfield in each transaction. Each transaction results in a change to theversion number of the vendor entity, identified by the fieldRevision_ID. FIG. 5 shows five different versions of the vendor, at fivedifferent points in time, starting at revision 1 as shown at entry 501.Entries 502-505 show subsequent versions of vendor Widget Co., over aperiod of three years. In particular, transaction 502 shows an addresschange, transaction 503 shows a bank account change, transaction 504shows another address change (back to the initial address), andtransaction 505 shows another bank account change (back to the initialbank account).

As an example of the operation of the invention, consider that theenterprise has a policy that indicates an exception in the case of avendor address change and bank account change followed by a changebackwithin a short period of time. Such an exception would be determined andreported in accordance with aspects of the invention. Although thisexample is given in the context of a financial type transaction, itshould be understood that invention has applicability to other types oftransactions including security applications, IT infrastructure,personnel management, health care, banking and financial institutions,logistics, and virtually any time of activity that involves anelectronic record or transaction.

Still referring to FIG. 5, in accordance with aspects of the invention,predetermined metadata 510 is associated with each entity upon storagein the monitoring database so as to facilitate preservation of ahistorical record (versions) of the entities over time. This metadatatypically includes, by way of example: an actor identification (such asthe name of the person that effected the change to the entity, indicatedby an Actor field), a timestamp (identified by the field Update_Time),and a revision number (identified by the field Revision_ID). FIG. 5illustrates that revision 3 of the vendor Widget Company experienced achange to the bank account identifier from 123453 to 123456.

The initial metadata of actor, timestamp, and revision number isassociated with initial selected data 515, to create the initial recordfor vendor Widget Company during the master extraction. It will ofcourse be appreciated that subsequent changes to various informationassociated with the vendor Widget Company includes different metadataidentifying the actor, timestamp, and an assigned revision number, toeach subsequent change, for record keeping purposes.

System Main Execution Loop and Configuration

FIG. 6 is a flow chart of a computer-implemented process 600 foreffecting the principal components of a transaction integrity monitoringsystem 100 constructed according to aspects of the present invention.From the discussion in connection with FIG. 1, it will be recalled thatthe various components of extractor 140, mapper 150, CORE 160, knowledgemaintenance 170, and analysis engine 180 all cooperate to effect aspectsof the inventions. Process 600 illustrates the principal operativecomponents of extractor, mapper, and CORE. Starting at step 602 andlooping at step 610, the process 600 begins by running programs 604 forimplementing the extractor 140, then programs 606 for implementing themapper 150, and then programs 608 for implementing the CORE 160. Theseprograms run repeatedly and continuously, so as provide for continuous,near real time operation to detect policy exceptions. Although theseprocesses are shown sequentially, they can be implemented asynchronouslyand independently. The processes for knowledge maintenance 170 and thetransaction analysis engine 180 are user-driven and asynchronous to theprocess 600, and are described elsewhere herein.

Those skilled in the art will understand that the system 100 willrequire initial configuration with predetermined information so as toallow their various functions to execute. A system constructed inaccordance with the present invention(s) is configured by anadministrator or other authorized user, prior to operation. Suchconfiguration involves establishment and expression of the enterprisepolicies in one or more enterprise policy statements, determination ofthe manner of extraction of data from monitored databases and providingextraction data, and determination of the mapping or normalization ofdata in the monitored databases to the enterprise ontology, so thatextracted data can be stored in the monitoring database for out-of-bandoperations and exception detection and management.

FIG. 7 is a pseudocode listing of a computer-implemented process 700 forsystem configuration that may be invoked through a user interface by anauthorized user such as shown at 101 in FIG. 1, for example anadministrator. Access is provided to the TIM system 100 for purposes ofinputting information required by the various components. In accordancewith known computer security techniques, user name and password securityor other security mechanisms are preferably employed to control or limitaccess to the configuration functions to trained and authorized users,in particular administrators who are knowledgeable as to functions ofthe system and information requirements.

The process 700 includes several subsidiary program functions, includingConfigureExtractor, ConfigureMapper, ConfigureCore, andConfigureWorkbench. These program functions or routines provide forconfiguration of the extractor 140, mapper 150, CORE 160, and aspects ofthe analysis and reporting functions 180, respectively.

The ConfigureExtractor routine includes steps for specifying enterprisesystems or other data sources from which data is acquired or provided,as well as specifying primary key fields, field identifiers, filters,context, and parameters of accessing remote data sources. From FIG. 1,it will be recalled that the extractor 140 may be of various types,including a programmatic extractor 141 a, master extractor 141 b, aresync extractor 141 c, a log extractor 141 d, environmental sourceextractor 141 e, or an external source extractor 141 f. The principalinformation required in the extraction functions is the identificationof the particular databases for which information is to be extracted,tables of such databases, any file pathnames required to access thetables, any routing information such as network or MAC addresses ofparticular computer systems, and, in certain cases, the identificationof particular fields within particular tables that should be extractedif during an extraction fewer than the entirety of a table is to beobtained.

The ConfigureMapper routine includes steps for specifying parameters andaspects of the staging database 155, the monitoring database 175, theontology files, entities involved or identified in an ontology, mappingsof data items for entities, and other contexts and parameters.Configuration of the mapper as utilized in the present inventioncomprises identification of particular data tables and fields of dataprovided by an extraction from a monitored database, and maintenance ofthe relationship between such particular tables and fields of themonitored database with corresponding tables and fields of themonitoring database. Such information is reflected by and stored in theenterprise ontology. The ontology in particular represents the mappingof fields from monitoring databases into particular selected fields ofthe monitoring database.

The ConfigureCore routine includes steps for defining a set of policystatements or frames, including identifying the transaction involved inthe policy, any required support entities, any indicators of the policy,and other frame or policy parameters. This routine enables a user toaccess to stored policy statements (as expressed in XML frames in thedisclosed embodiment) so as to create new statements, update existingpolicy statements, activate or deactivate particular statements, changethe sequence of statement (frame) execution, and provide any otherrequired administrative functions for determining or modifying the logicor expressions associated with frame execution.

The ConfigureWorkbench routine includes steps for configuring access tothe monitoring database (to obtain related entities), setting usernamesand permissions, and configuring any reporting functions of the system.This routine enables a user to input or correct information associatedwith the analysis server, such as the configuration and contents ofreports, alarms, status, cases, and other information associated withthe provision of information relating to exceptions as determined byoperation of the TIM system 100. Further details are provided below asto specific user interfaces relating to case management and reportingfunctions.

The process 700 operates in a continuous loop to monitor for user input,receive authorization information in the form of user name and password,test for a condition for actuation of one or more of the configurationfunctions, and permit access to the desired configuration functionthrough a user interface (not shown) applicable to the informationalrequirements of the functions being configured.

Extractor—General Overview

Turn next to FIG. 8 for a detailed written description of aspects of thedata extractor 140 and its operation to extract or retrieve informationfrom various enterprise databases (data sources) and provide suchinformation to a staging database 155 prior to a mapping operation by amapper 150. As discussed in connection with FIG. 1, the data extractorcomprises six principal components: a programmatic extractor 141 a, amaster extractor 141 b, a resync extractor 141 c, a log extractor 141 d,an environmental extractor 141 e, and an external source extractor 141f. Aspects of each of these different types of extractors will bediscussed in turn.

FIG. 8 is a pseudocode listing of a process 800 for the extractor 140,and illustrates aspects of the subcomponents of the extractor. Anextractor knowledge file (extractor file) is provided for each datasource from which data is obtained for use in policy complianceanalysis. Extractor files (data) are stored in the knowledge base 165.For each data source, an initial extraction is effected by aMasterExtractor routine to obtain an initial set (or selected subset) ofdata from the data source, which is typically stored or cached in thestaging database 155. Subsequent to an initial extraction, a routineSyncExtractor is run to maintain databases between the staging databaseand source databases in synchronization, at an interval determined by aparameter SyncInterval. If a log file is used to provide changed data, aLogExtractor routine is run. If data is provided programmatically from adata source such as an SAP ERP, a ProgrammaticExtractor routine isexecuted. The process 800 runs repeatedly in a loop, as data extractionis a repeated, continuous operation.

A system constructed as described herein pulls data from various andsometimes heterogeneous sources, such as ERP systems, network logs, andother enterprise systems, hereinafter referred to as “source” systems,transforms the information via the enterprise ontology, and populatesthe monitoring database, also called the “target” system or database.

It will be appreciated that data corresponding to monitoring entitiesmust be pulled frequently, preferably continuously, but not necessarilyin real time. This minimizes the chance that fraudster can cover tracksby changing data back. Near real time data extraction is preferably inthe range of several minutes, although this time period is arbitrary. Incases where data is retrieved by way of a detailed log (e.g., an auditlog), frequency of extraction is less important since all changes to theERP databases are logged anyway.

As discussed above, if updates to entity information are pulled via achange log, preferred embodiments provide for initial population of thetarget database utilizing the mapping transformations required by theenterprise ontology. Furthermore, because of the possibility that thesource and target data will get out of synchronization if a change logis exclusively used, the resync extractor 141 c provides for resyncingthe data between a source database and the target database. Thoseskilled in the art will understand that re-syncing is a snapshotmechanism, so frequency is an important parameter. Non-log changes arebelieved to occur in batch jobs, so that daily or nightly resyncing ispreferred.

Applications of the present invention will draw data from enterprisesource systems comprising ERP system manufactured by various vendors. Itis important not to disrupt the mission-critical operational system ofan enterprise. Preferably, therefore, data extraction is usually in theform of simple queries, without additional constraints, joins, orfollow-on queries.

In some aspects of the invention, target entity tables in the stagingdatabase or in the monitoring database are not necessarily exactlycopies of the source tables. Table names, fields, data types, and evenvalues may have to be transformed according to the system ontology. Inaccordance with aspects of the invention, each update in a source entitythat is monitored should result in creation of a new “revision” createdin the target or monitoring database. This advantageously allows the TIMsystem to retain and reason about past updates. Further details aboutthis mapping are provided elsewhere.

The programmatic extractor 141 a is operative in connection with datasources that do not provide for direct query access to data contained inthe databases, for example certain SAP ERP systems. Further details ofthe programmatic extractor are provided below.

The master extractor 141 b is operative for an initial or master dataextraction, at initial start up of a TIM system 100 constructed inaccordance with the present invention. According to certain aspects, anentire initial dataset, which may consist of entire data tablesrepresentative of a “snapshot” of the state of the enterprise data atinitial point in time, is obtained by the master of extractor 141 b andprovided to the staging database 155. Those skilled in the art willunderstand and appreciate that the master extractor 141 b is preferablya high-speed data interface that retrieves information at the maximumrate possible from connected ERP systems with immediate storage in thestaging database 155, without any further data processing operations, tominimize the data processing load on the ERP system. Subsequentoperations of mapping may therefore be done “out of band” relative tothe operation of the ERP systems, to minimize the impact on timeresponsiveness and other operations. Further details are provided below.

The resync extractor 141 c provides for a synchronization operationbetween the monitoring database and any associated monitored (source)databases, typically on a periodic basis, to compensate for loss of datasynchronization that can occur over time, e.g. by reliance on log files.Further details are provided below.

The log extractor 141 d provides for data extraction based oninformation provided by a data source in the form of a log or auditfile, which typically contains selected information identifying a changeto an entity. Further details are provided below.

The environmental source extractor 141 e provides for data extractionfrom data sources associated with the system environment of anenterprise, e.g. its IT infrastructure such as firewalls, intrusiondetection devices, routers, servers, etc. Such information is typicallyadditional or supplemental to entity information, and can providecorroborating evidence for instances of errors, fraud, or misuse. Forexample, a repeated pattern of failed username/password attempts to anenterprise system might be indicative of a hacking attempt. If a user isfinally successful in gaining access to a system (i.e. guessing thepassword), and thereafter perpetrates a fraudulent payment request in anA/P module using the same username, the log file of failed accessattempts indicates that it is likely that the fraudulent paymenttransaction was likely generated by the same person that hacked thepassword after several failed attempts.

The external source extractor 141 f is an interface to external datasources, e.g. public and/or proprietary data sources, that might providesupplemental information utilized in implementing certain enterprisepolicies, e.g. verification of a driver's license number, or a telephonenumber in an online telephone directory, or other similar data sourcethat is not necessarily a direct part of the enterprise's computinginfrastructure.

The disclosed embodiments of the TIM system 100 and methods thereof areoperative with various different classes of data sources. One type ofdata source is a synchronous polling type database, such as PeopleSoft.In the case of this type of data source, the extractor preferably makesa JDBC connection to a database table and pulls its contents into thestaging and/or monitoring database for further processing.

A second type of data source is a synchronous polling type database withan RFC/API. For this type of data source, the extractor uses an externalsystem API and protocol to poll for new information that can beretrieved, transformed, and loaded into the staging and/or monitoringdatabase. This type of data source includes SAP R3, and constitutes aprogrammatic type extraction.

A third type of data source is an asynchronous event broker type system.For this type of data source, the extractor must register with a databroker that sends events asynchronously as transactions as state changesoccur in the enterprise system. Examples of this type data sourceinclude PeopleSoft EIP and SAP Netweaver type event brokers.

A fourth type of data source is an asynchronous file sending typesystem, such as SAP R3 ABAP cluster table. For this type of data source,the extractor initiates a program or script on an external machine thatprovides the actual extraction from the data source. Upon completing theextraction the external program sends the data to the extractor. Thistype of data source also constitutes a programmatic type extraction.

Each data extractor 141 makes reference to extractor data in the form ofan extractor file stored in the knowledge base, for information specificto the data source from which data is extracted. In this regard, FIG. 9illustrates an exemplary extractor file 900 according to aspects of theinvention. Typically, each extractor file provides predeterminedinformation needed to (a) access a particular data source, and (b)determine what specific data from that data source is to be obtained,i.e. what particular fields from what particular tables, and (c) wherethat data is to be stored or cached in the staging database. Thus, theexemplary extractor file 900 includes parameters or tags for adescription of the extraction <description>, identification of the datasource <extractor_name>, a source table identifier in the data source<source_table>, a target or destination table identifier in the stagingdatabase <staging_table>, one or more key fields <key_field> thatidentify keys to table(s) that are to be extracted, and one or more datafields <field> that identify particular data fields that are to beextracted. If desired, filters and queries can be embedded into the fileto filter or retrieve particular data items.

FIG. 10 illustrates a multi-stage data extraction in accordance withaspects of the inventions. The numbered arrows indicate a typicalsequence of data extraction for use in carrying out the invention.Typically, the master extractor 141 b (or an initial run of aprogrammatic extractor 141 a, if a data source requiring programmaticextraction is utilized to provide transaction data) is run first toobtain an initial data set and store that initial data set in thestaging database 155. This is shown by the arrows labeled “1”. Next,changed data is typically identified, by use of (a) a programmaticextractor 141 a if the data source provides data in that manner, or (b)a log extractor 141 d if changed data is identified by reference toaudit or transaction logs, or (c) a resync extractor 141 c if aresynchronization operation between the ERP database 121 and stagingdatabase has triggered. Such change data identification is shown by thearrows labeled “2”. Next, any external data or environmental data fromadditional data sources 130 is pulled in by operation of an externaldata extractor 141 for an environmental extractor 141 e. Such additionaldata is shown by the arrows labeled “3”. In this manner, data isobtained from multiple, possibly heterogeneous, distributed, anddisparate systems for use in policy analysis and exceptiondetermination.

FIG. 11 provides an example of how changed entities are detected andidentified, by receipt of changed data from an exemplary ERP database121. Table 1110 illustrates an exemplary vendor table that shows aplurality of support entities, i.e. vendors in an accounts payablesystem, at an initial data load or extraction by a master extractor, attime t1. Assume that an actor makes a number of changes to informationrelated to a particular vendor, say Vendor 1, over a period of time,e.g. an address change, a bank account change, and address change backto the original address, etc. Table 1120 illustrates a plurality ofprior versions of the entity Vendor 1 at various points in time t1, t2,t3 . . . up until a current version at time t_last_update. Assume aseries of further updates (changed data) to Vendor 1 occur; these arenew data that are pulled into the staging database by the log extractoror resync extractor (as applicable). These new changed data items 1122are shown as entities Vendor 1 @ t_new_(—)1, t_new_(—)2, t_new_(—)3,etc. in the table 1120. These new entities (new versions of Vendor 1)will be transformed into monitoring entities by operation of the mapper150, which creates monitoring entities corresponding to these newversions of Vendor 1 in the monitoring database 175.

From the foregoing, it will be understood and appreciated that aspectsof the invention involve an initial data load to obtain an initial setof data that is analyzed for exceptions, followed by a “detect changes”type operation to minimize the load on the ERP systems by extractingchanges to certain entities, as reflected by changed data.

Programmatic Extractor

As mentioned above, a programmatic extractor 141 a is utilized forenterprise databases that do not permit direct extraction. Those skilledin the art will understand that certain types of enterprise systems donot permit direct access to data tables or information stored therein.For example, certain SAP products do not provide an interface forexternal queries to data stored within its databases. However, the SAPproduct provides a scripting language that allows users to writeprograms to cause the export of selected data for external use. The SAPsystem and other similar systems output information in response tointernal execution of such a script or program. The programmaticextractor 141 a therefore represents the combination of (a) a scriptingelement operative internally to systems such as SAP that do not providedirect data querying, for internal retrieval of selected data andexporting such selected data, (b) a communications interface or filetransfer mechanism for communicating data exported, and (c) a softwarecomponent in the extractor 140 responsive to exported data from ascripting type export operation, for receiving this data andtransmitting the data to the staging database or for other utilization,e.g. in the case of staging database bypass for small amounts of datathat do not require staging to minimize performance degradation.

The system SAP R3 does not provide a data extraction interface thatallows direct integration with an application program interface (API)that would permit direct data extraction. Nor is it possible tointegrate directly with the underlying SAP database due to the presenceof proprietary cluster tables. As with other types of ERP systems, SAPR3 contains many tables that will contain information comprising entitydata. With some systems, a synchronous database query protocol can beused to periodically replicate tables of interest from SAP R3 into themonitoring database. It will then be possible to reuse existingalgorithms to handle merge and loading behaviors.

However, many high volume data entities are stored in SAP R3 as“cluster” tables. These kinds of tables essentially store information asa column set for a table, in a single compressed proprietary data blockinside a column in the cluster table. Other columns in that roll containmetadata such as key fields and values so that the “cluster” of data canbe accessed and read or written as needed. The cluster table storagemethod used by SAP presents an issue for data extraction because thereis no published specification for the compression algorithm or the dataformat used in the cluster. In such cases, and with other similarlyconstructed systems, information stored in cluster data can be made inR3 open SQL interface. An open SQL interface is available to ABAPprograms as an internal API.

Accordingly, it will be understood that programmatic extractor 141 a isinvoked externally, but essentially comprises an independent processeffected by a script or code 1210 that runs within a clustered typeenvironment such as that provided by SAP, and returns a reply containingrequested information to the programmatic extractor 141 a. In thismanner, the programmatic extractor 141 a provides a synchronous sourceinteraction with data storage systems of this nature.

FIG. 13 is a pseudocode listing of exemplary computer-implementedprocess 1300 for a programmatic extractor. The illustrated processEnterpriseSystemPlugin illustrates the steps taken within a system (suchas SAP) that requires programmatic extraction, and corresponds to theprocess 1210 in FIG. 12. Essentially, this process queries for changeddata fields to any updated tables within the ERP system, and exports ortransmits that data to the TIM system 100, where it is received by theprogrammatic extractor. The process ExtractorListener provides stepswithin the programmatic extractor for receiving data from theEnterpriseSystemPlugin process, determine if any new rows of data (newdata records) have been created, and insert the appropriate selecteddata items that are received into corresponding fields in the stagingdatabase. Similar steps are taken in the event of updated records orfields as opposed to new data records.

Master Extractor

FIG. 14 is a pseudocode listing for an exemplary computer-implementedmaster extraction process 1400 in accordance with aspects of theinvention. Typically, a master extraction is a one-time operation topull in a significant initial data set from a data source such as anenterprise system. This process typically involves steps forinitializing a connection to the data source from which the masterextraction is to occur, followed by steps of querying selected rows(fields) for all rows in all tables identified for the extraction, asspecified in the corresponding extractor file. After the query and datais received, the data is inserted as new rows in the staging database155, and the database connection is closed.

Other conditions for triggering a master extraction can occur, forexample, in the event that a system administrator determines that themonitoring database is grossly out of sync with a monitored database andelects to “start over” with a new master data extraction. Otherequivalent conditions for a master data extraction will occur to thoseskilled in the art.

Log File Data Extraction

FIG. 15 illustrates aspects of a transaction log file 1500, provided asa means for extracting information from certain types of data sources.The log extractor 141 d is responsive to a log file 1500 to process thelog file and extract data from an ERP system in accordance therewith. Anexemplary transaction log file 1100 comprises a plurality of entries1502, each typically including certain log file metadata 1504 relatingto the information such as a timestamp, identification of a user oractor responsible for making the change or creating the log entry, andother relevant information relating to the entry. Relevant databaseupdates are also provided as a part of the entries 1502 and identifyparticular fields and values of the changes to data indicated by eachrecord in the transaction log file. For example, the entry 1502 aindicates that a vendor AAA Inc. was added to a vendor table, entry 1502b indicates that a purchase order was issued to the vendor identified asAAA Inc., while entry 1502 c indicates that a new vendor BBB Inc. wasadded to the vendor table. All these transactions were effected by thesame actor, John Doe, as indicated in the metadata.

A log file might, or might not, provide the actual information that isdesired for storage in the monitoring database. If so, no further dataextraction operations would be required. If not, the log extractor 141 dexecutes instructions to query the relevant database and obtain theneeded data.

FIG. 16 is a pseudocode listing of a computer-implemented log extractorprocess 1600, according to aspects of the invention, operative toimplement a log extractor 141 d. As with many other processes andaspects of the present invention, the log extraction process 1600operates as a continuous loop testing for the conditions that trigger alog extraction operation. For example, such conditions include theinquiry of a file that contains a list of unprocessed log files, or at apredetermined time.

As known to those skilled in the art and as illustrated in FIG. 15, alog file comprises a list of transactions, comprising metadata and otherinformation that corresponds to the transactions are involved. Aninitial step is to receive a log from a data source that has new data orchanged data. The log file is inspected for new log entries. For eachnew log entry, a temporary row is created in a temporary file or table,metadata from the log is appended (if not provided in the log), a queryis made to the data source to obtain selected data fields for the record(row) involved in the addition or update, and upon receipt of the datafrom the data source (or parsing from the log file, if the data isprovided embedded in the log file), the data is added to the temporaryfile. Then, for each row in the temporary file or table, a determinationis made whether there is new data (a new row) or updated data (updatedfields in existing records or rows), and the data for the selectedfields is inserted into the staging database. Status data (such as a“modified” flag and/or timestamp) is further appended to flag the dataas new or changed, for the mapper or other processes.

Resync Extractor

FIG. 17 is a pseudocode listing of a computer-implemented resync process1700 according to aspects of the invention that comprises the operationsof a resync extractor 141 c. As with other processes described herein,the process 1700 operates in a continuous loop testing for theconditions that call for a resync type extraction. Examples of suchconditions include the passage of a predetermined amount of time, or ata predetermined time such as the same time every day, night, week, etc.Another condition is the indication by other processes, not shown, of anout-of-sync condition between a data source and the staging database.

A re-sync or resynchronization operation essentially ensures consistencyof data between a data source table and a corresponding table in thestaging database. Such an operation is typically run periodically so asto ensure that the source tables and staging database table reflect thesame information.

The resync process 1700 includes steps for determining new and modifiedrows in a table of a data source, and creating new rows in the stagingdatabase for any new records added that were not previously detected oridentified in a log file. The process typically applies to each datasource table that has a counterpart in the staging database. A procedureDetermineNew And ModifiedRows is operative to compare the contents ofthe tables in the data source table and the corresponding stagingdatabase table and determine if any new rows have been added or anyfields of existing rows were changed. If so, the staging database tableis updated.

Additional Data Sources Extraction

Although not directly illustrated, extraction processes similar to thosedescribed above are effected to obtain additional data from additionaldata sources such as external data sources 132 and environmental datasources 133 (FIG. 1). Those skilled in the art will understand thatcomputer programs or processes substantially similar to those above areutilized to extract and obtain additional data from such additional datasources for utilization in policy statement compliance monitoring.

Mapping OF Monitored Entities to Monitoring Entities

With the foregoing extraction processes and structure having beendescribed, turn next to FIG. 18 for an illustration of an exemplary dataextraction of a series of related business transactions andtransformation of the data into monitoring entities, to illustrate theprocess of data captured by the extractor 140 in accordance with aspectsof the invention. On the left hand side of the figure is a series ofbusiness transactions that comprise monitored entities in accordancewith the invention. Such entities are identified as vendor accountcreation 1802, purchase order processing 1804, purchase receiving 1806,invoice and vouchering 1808, with the final step of payment issued 1810.In accordance with the invention, data corresponding to these varioustransactions generated by the responsible and monitored ERP system are(1) extracted from the data source in which electronic transactionrepresenting these business activities are stored, (2) stored in thestaging database, (3) transformed by the mapper into monitoringentities, and (4) stored in the monitoring database as monitoringentities. As monitoring entity, each transaction is identified with anentity name (e.g. a vendor account creation activity 1802 becomes anAccount Created monitoring entity 1813) and associated with metadata1812 including a timestamp, actor, and revision number, to facilitatetracking and comparison of entities representing such transactionshistorically and comparatively in the event that changes are made inviolations of enterprise policy.

For example, the vendor account creation transaction 1802 generates anAccount Created transactional monitoring entity 1813, bearing revision1, with a timestamp as shown, with the actor indicated as John Doe. Thisis an example of a static monitoring entity in that the creation of avendor account within an ERP system will tend to persist for an extendedperiod of time. The subsequent transactions with monitoring entity namesPO Issued 1814, Received Purchase 1816, Invoice Received 1818, andPayment Issued 1820 are considered transient or transactional entities.In accordance with aspects of the invention, each of these transactionalentities is recorded in the monitoring database as monitoring entities,with appropriate metadata.

Mapper

FIG. 19 schematically illustrates the operation of the mapper 150 inaccordance with certain aspects of the present invention. The mapper 150operates in accordance with information stored in an ontology sourcetable 1911 that comprises the enterprise ontology with respect to theparticular data source involved in an extraction. The ontology sourcetable 1911 contains information that correlates tables, fieldnames,field parameters, data types, etc. from various enterprise sourcedatabases to corresponding tables and fields in records comprisingmonitoring entities stored in the monitoring database 175. For examplethe ontology source table identifies particular tables and fields in theERP database, e.g. tables 1916, 1918, 1920. The mapper effects varioustransformations and renaming required to store data sourced from thesesERP database tables as entries in the monitoring database.

According to an aspect of the invention, information required by themapper to conduct its mapping and transformation operations is providedin an ontology file and a mapper file retrieved from the knowledge base.An exemplary ontology and mapper files are discussed elsewhere herein.

According to another aspect of the invention, information required bythe mapper for its operations is provided in an ontology target table1912 that provides information that identifies field names andparameters of the data, after mapping, as the data is stored in themonitoring database. The ontology target table 1912 also identifies whatmetadata 1915 is associated with each entity provided by an extraction.Examples of metadata include but are not limited to a revisionidentifier (Revision_ID), a unique entity identifier (Entity_ID), anentity version (Entity_Version), a person or actor associated with thetransaction (Actor_ID), and a timestamp or time identifying the lastupdate to the entity (Update_Time). Other types of metadata can also beutilized for other purposes, for example, a unique object identifiercould be generated and assigned to the entity as it is reflected in themonitoring database.

The mapper carries out the following basic steps: (1) map an ERP sourcetable name to a target table name in monitoring database; (2) map asource table field name to a target table field name in the monitoringdatabase; (3) if required, map a predetermined set of source fieldvalues into single target field value (e.g., if multiple address linesare provided in a source table that are mapped to a single data item orfield in the target table); (4) collapse any required “child” tablesinto a single parent entity and a target table in the monitoringdatabase; (5) populate metadata fields in the target table includingrevision identifier, entity identifier, entity version, actor, andupdate time; (6) for each new entity revision for an entity preexistingin the monitoring database, duplicate the existing monitoring entity andcreate a new revision, i.e., in the monitoring database table.

If a change log approach is used for information from the ERP databases,which often records individual field updates in ERP databases asseparate entries, changes to a particular entity that occurred withinthe same transaction (as determined by the change time and actor ID) arepreferably combined into a new entity revision.

The mapper 150 may further require a query to a source database in theevent that certain information needed to create a monitoring entity isnot immediately available from an entry provided. For example, anaddress record update for a static entity such as a vendor or employeemight not contain a reference to the particular address information thatconstituted the address change. If the ERP system is so constructed,this information must be obtained via a query from the source database.It will be understood that information could potentially be obtainedfrom the target or monitoring database, obviating a copy of additionalinformation from the ERP system.

It will be appreciated that the mapping operations conducted by themapper 150 could, were such operations not segregated to separatecomputing processes, create an additional load on the ERP systems dataprocessors. In accordance with the aspects of the invention, the stagingdatabase 155 provides a cache of information from the source databases,thereby facilitating mass copy operations from the ERP system. Such acaching architecture is more computationally efficient than conductingmapping operations in real time as data is received, and reduces thedata processing load on ERP systems. This is believed to provide asignificant architectural advantage for embodiments of the presentinvention. It will therefore be appreciated that this architectureminimizes the complexity and computational load on any component thatruns remotely from the TIM system 100. Furthermore, the partition offunctionality into logical steps of extraction, caching, and mappingprovides for an architectural separation of functions and asynchronousoperation to improve performance.

It will thus be appreciated that an asynchronous architecture withstaging database caching allows the processes of extraction and mappingto optimize the rate at which data is provided from ERP systems, andthat mapping operations can occur out-of-band (i.e. offline), at timeswhen ERP systems have reduced workload, to improve performance.

FIG. 20 is a pseudocode listing for a computer-implemented process 2000for effecting a mapper 150, in accordance with aspects of the invention.As with other computer-implemented processes described herein, process2000 is preferably implemented as a computer program that executes on acomputer system that runs the TIM system 100. As in other processes, themapper process 2000 runs as a continuous loop testing for conditionsthat trigger its execution. Such conditions include the detection of newdata in the staging database 155, or the provision of a command orparameter indicating it should run, or other similar condition.

The process 2000 comprises steps for creating tables in the monitoringdatabase, retrieving data from the staging database, conductingtransformations and renaming of selected fields in accordance with theenterprise ontology, and storing the transformed data in monitoringentity data records in the monitoring database. A processCreateTargetTables reads an ontology file corresponding to theparticular data source that is providing entities for processing,creates a table in the monitoring database, creates meta data for thetable such as pointers to related entities and predetermined text thatdisplays in connection with the entity.

A process Mapper comprises steps for opening a connection to the stagingdatabase 155, opening a connection to the monitoring database 175,reading a corresponding mapper file to obtain information required forthe data renaming and transformation (which may include base mappingsprovided with the system as well as custom mapping resulting from acustomization operation to a base mapping), and validating the mappingsto ensure consistency with the ontology. Then for each table in themonitoring database that is to receive transformed/mapped data, stepsare taken to query/join source staging tables to retrieve particulardata items or fields, perform any necessary table or fieldtransformations, compute any additional fields, mark the previousversion (revision) of the entity as “old”, save the new fields as a newcurrent version (revision) in the monitoring database, and set a “new”flag to indicate that a new monitoring entity is ready and available forprocessing by a policy statement.

The mapping table or enterprise ontology, it will be recalled fromearlier discussion, stores information and establishes the mappingbetween predetermined tables, fields and parameters of a source(monitored) database and corresponding tables, fields and parameters inthe monitoring database. The mapping, transformation, and renaming ofdata from the source data format (monitored database) to the target dataformat (monitoring database) is also referred to as normalizing.

FIG. 21 illustrates an exemplary mapping 2100 according to aspects ofthe present invention, and specifically illustrates how a subset of dataitems from a data source table are selected and renamed to become dataitems corresponding to a monitoring entity stored in the monitoringdatabase. This illustrative example assumes an accounts payable system(A/P) associated exemplary accounts payable source database, asreflective by an ERP source table at 2101. In this example, there are inexcess of 130 fields of information in various tables in the ERP datasource that store information relating to the enterprise's accountspayable function. In accordance with aspects of the invention, only alimited subset (a selected reduced subset) of these fields may berelevant or needed for the enterprise policy statement containing rulesrelevant to accounts payable transaction integrity monitoring.Accordingly, the example assumes that there is a predetermined set ofpolicy statements (XML frames) that rely upon and utilize particulardata items from the accounts payable source table 2101 that are relevantfor execution of these particular frames. In the example in shown inFIG. 21, it is assumed that only 21 fields are utilized in the logic ofthe policy statement for determination of indicators, as shown by thetarget table 2121. From the entirety of the set of fields from theoriginal dataset 2101, the fields in the mapped and reduced subsetinclude exemplary fields 2125 identified as Voucher_No, Business_Name,Invoice_No, Vendor_Name, etc. as well as predetermined metadata.

The mapper is responsive to an ontology source table 2111 to select onlythe needed data items from the source database in table 2101 and storethose items as identified by the field names shown in the target table2121, in the monitoring database 175. Also shown in FIG. 21 is a mappingfile 2131 and an ontology file 2132, as preferred approach to reflectinginformation needed by the mapper 150.

In addition to the selected subset of information from the source table2101, and as was previously described, predetermined metadata is addedto each entity created and stored, e.g. Revision_ID, Entity_ID,Entity_Version, Actor_ID, Update_Time. It will be further understoodthat the mapper 150 is responsive to a stored ontology mappingpredetermined source table data fields to predetermined target tabledata fields and including predetermined metadata, for purposes ofcreating monitoring entities in the monitoring database, on which thepolicy statements are executed in order to identify a possible policy ofviolations.

FIG. 22 illustrates an exemplary mapping file 2200 that contains datautilized by the mapper 150 in accordance with aspects of the invention.In preferred embodiments of the invention, the mapping file containsinformation needed to identify the source tables, entity names, targettables, and other required information. For example, the mapping file2200 includes entity definitions delimited by entity tags <entity>, withassociated information identifying a data source <source></source>,table names <name>, any database join operations that might be requiredto obtain the required data from multiple tables <join></join>, keyfields that might be required <key></key>, field names within tables<field></field>, and a mapping of the corresponding filed name andtable, e.g. a field with the name VENDOR_ID obtains its data from thesource table and field VAB.ABALPH, as shown in the figure.

FIG. 23 illustrates an exemplary ontology file 2300 according to aspectsof the invention. As with the mapping file 2200, the ontology file isutilized by the mapper 150 to effect data transformations and mappings.The preferred ontology file is expressed in XML, and includes a numberof data items, identified with XML tags, that are required to createtables in the mapping database and set up appropriate fields and namesthat may be utilized in creating and executing policy statements orframes. For example, the exemplary ontology file includes informationidentifying an entity that is a monitoring entity in the monitoringdatabase, shown as <entity></entity>. This entity includes certain dataitems such as a name <name></name>, a title <title></title>, adescription description></description>, an identifier <typeid></typeid>,and a linkage to one or more related entities <linkage></linkage>. Theontology file also includes one or more field identifiers<field></field> that specify data fields of records in the monitoringdatabase; each of these fields has a corresponding name, description,and type, as identified with corresponding tags.

Knowledge Base, Core, and Frame Execution

FIG. 24 is a block diagram of a knowledge base 165 according to aspectsof the present invention. The knowledge base 165 comprises severaldifferent data items that are utilized by various computer-implementedprocesses of the inventions. An extractor knowledge base (KB) 2405stores one or more extractor files, as have been previously describedherein. Such extractor files are identified as source tablespecifications or specs in the figure, e.g. Source Table Spec 1, SourceTable Spec 2, etc. An ontology store 2410 stores one or more ontologyfiles, as are described elsewhere herein. Such ontology files areidentified as target table specifications or specs in the figure, e.g.Target Table Spec 1, Target Table Spec 2, etc. A mappings store 2415stores one or more mapping files, as are described elsewhere herein.Such mapping files are identified as target mappings in the figure, e.g.Target Mappings 1, Target Mappings 2, etc. A frames store 2420 storesone or more computer-executable policy statements, in the form of XMLframes in the disclosed embodiments, as are described elsewhere herein.Such frames files are identified as Frame 1, Frame 2, etc.

All of the specifications in the various knowledge base files can bemodified and overridden element by element by more customized knowledgefiles, as described below. In addition, individual files include acontext mechanism allowing individual tags within the knowledge files tobe filtered on a run context, which is specified when the system isinstalled and run for an enterprise. These are only used of the contextspecified matches that for the specific installation. Finally,individual parameters can be set in the knowledge files, values forwhich are also set as installation for run time. This provides a thirdmeans of customizing knowledge files, including extractions, mappings,and frames.

FIG. 25 is a pseudocode listing of an exemplary computer-implementedprocess 2500 for operations of the CORE execution process 160 (FIG. 1)according to aspects of the present invention. As with othercomputer-implemented processes, the CORE execution process 2500 isasynchronous and executes on the computer system running the TIM systemprogram modules. As with other processes utilized in the invention, theprocess 2500 is a continuous loop that runs continuously, testing forthe conditions that cause it to execute. Such conditions include, by wayof example, the completion of a pass through all available policystatements, or completion of a predetermined subset of such policystatements, or at predetermined time intervals, or in response to acommand to execute a particular policy statement. Other conditions forexecution will occur to those skilled in the art.

The CORE process 2500 comprises steps for retrieving computer-executablepolicy statements (frames) from the knowledge base 165 and executingthem on data (monitoring entities) in the monitoring database 175. Thepreferred data structure for the computer-executable policy statementsor frames is described in greater detail elsewhere. These steps includeopening a connection to the monitoring database, retrieving and readingany base frames that are configured to run, retrieving and reading anycustom frames that are configured to run, and validating the frames forsyntax. Then, for each frame so retrieved, the system computes anyrequired statistics tables, and for each new version (revision) of amonitoring entity, and for all applicable and required support entities,evaluates all indicators in the frame. Such operation may requireretrieving additional information from additional data sources, asdiscussed elsewhere. If the evaluation of any indicator produces aconfidence level that exceeds a predetermined threshold, a new exceptionis created. Exceptions can be based on the absence of specific entitiesas well as on specific patterns of data in existing entities. Exceptionscan also be based on the results of previous exceptions, therebyproviding a form of chaining reasoning wherein subsequent transactionscan be used to build on the conclusions related to previoustransactions. This new exception is added to the exception database, ina format (data model) described elsewhere herein. Any required potentialimpact and probabilities are computed. A natural language description ofthe exception is generated based on a template in the frame, all basisrevisions are determined and saved, and a wariness value for each entityunderlying the exception is updated based on the exception. Basisrevisions are the entities (actually a specific revision of theentities) upon which an exception is based. This includes the singletransactional entity (i.e. the new revision of an entity that haschanged) and any supporting entities (revisions thereof) required tomatch the pattern in the frame. These are used to provide acomprehensive event view of the exception to the user in the UI (seebelow). Additional computation is performed to identify transitive linksbetween entities and exceptions, which are used in the link analysisfunctionality in the UI.

Exemplary Enterprise Policy and Exception

FIG. 26 illustrates an exemplary policy and exception that might be madethe subject of an enterprise policy and expressed as acomputer-executable policy statement (or frame) in accordance withaspects of the present invention. Valid and invalid business transactionsequences are is shown in the figure, so as to illustrate certainexemplary transactions that might occur during typical business activityand how an invalid sequence might be detected. The exemplary typicalbusiness transaction sequence involves creation of a new vendor accountat 2602 reflective of an enterprise determining that a new vendor shouldbe added to its accounts payable process. Logically, a vendor accountmust be created before any purchase orders can be issued to that vendor,purchases made, invoices received, and payments issued. These otherbusiness activities are shown as purchase order processing 2604,purchase receiving 2606, invoice and vouchering 2608, with paymentissued 2610.

The right hand side of FIG. 26 illustrates that a payment has beenissued at step 2616, which would only logically be expected after apurchase has been received 2618, and invoice and vouchering activity2620.

In accordance with aspects of the invention, a frame can be constructedto track the logical business activity steps and impose the discipline(i.e. enterprise policy) of a particular sequence in a business processof an enterprise, and to indicate a policy exception in the event that aportion of a business transaction sequence is out of order. Thoseskilled in the art will understand that information pertaining to eachof these particular activities involved of the process must be reflectedas transactional entities in a system of the present invention, and thatappropriate metadata such as timestamps associated with the particulartransactions must be inspected so that a determination of sequence canbe established. For the foregoing, those skilled in the art willunderstand that many other business activity and transaction policiescan be implemented by utilizing the techniques and methodologies of thepresent invention.

FIG. 27 illustrates another enterprise policy exception in the form ofan overridden transaction 2720. This figure also illustrates how thebusiness activities or transactions 2700 of the enterprise might bereflected as transactional entities 2710, as such transactional entitiesmight appear and be stored as monitoring entities in the monitoringdatabase in accordance with aspects of the invention. On the left handside is a sequence of exemplary and illustrative business transactions2700 of business and their counterpart transactional entities 2710, assuch transactional entities might appear as exemplary monitoringentities stored in the monitoring database. Each of the transactionalentities 2710 is shown together with corresponding metadata in the formof revision, timestamp, and actor.

Note the group of transactions shown at 2720, which is provided as anexample of an overridden transaction. The expected sequence of businesstransactions would be creation of a vendor account 2701, purchase orderprocessing 2702, purchase receiving 2706, invoice and vouchering 2707,and payment issued 2708. An inappropriate or invalid set of transactionsmight occur if a certain actor within the enterprise changed thevendor's bank account number at 2721, issued a payment at 2722, and thenchanged the vendor's bank account number at 2723 back to the originalnumber that was input during the vendor account creation. This is anexample of a typical fraud where an insider employee changes bankaccount numbers or other payment type information of a vendor so as tomisdirect or misappropriate funds from the enterprise, and then attemptsto “cover his tracks” by changing the bank account or other paymentinformation back to the initial invalid setting.

According to aspects of the invention, each version of particularentities, and in this case the static entity of vendor withcorresponding bank account number, is preserved as an historical record.A frame expressing the exemplary policy statement that “any changes ofbank account numbers of vendors followed by changeback within apredetermined time period constitutes an exception to be investigated”can be easily written and utilized in embodiments of the invention. Sucha frame or a group of frames expressing related policies can be executedto inspect a pattern or series of changes to particular entities, withthe purpose of determining if policy exceptions have occurred.

In the example described, the enterprise has a policy that such anexception should be indicated. The right hand side of FIG. 27illustrates the various transactional entities that would be created inimplementing this particular exemplary policy and exception. Thoseskilled in the art will understand that many other types of businesstransaction sequences, patterns, information requirements, controls, andthe like can be similarly implemented, as will be discussed in greaterdetail in connection with the frames and their execution.

FIG. 27 also illustrates the example of dual payments being issued inconnection with the example shown therein. At 2722 a first payment wasissued, and at 2708, a second payment was issued, perhaps against thesame vendor, but at a different account number than the first payment2722. The occurrence of dual or duplicate payments is yet another typeof policy exception that an enterprise may wish to monitor and identify.

FIG. 28 illustrates further aspects of the exemplary policy exceptionsof overridden transaction and duplicate payments of FIG. 27. On the lefthand side of FIG. 27 are the transactional entities 2710, as describedin connection with FIG. 27. The right hand side illustrates exemplaryresultant exceptions 2800 in accordance with aspects of the invention.

In the example of FIG. 28, one or more policy exceptions might bedetermined from the sequence of transactions illustrated. One exemplaryexception 2801 is that a vendor bank account changed, perhaps withoutsupervisor approval or other controls. Another exception 2802 is aninvalid sequence due to a payment being issued prior to receipt of aninvoice. Another exception 2803 is another change to a bank account of avendor. Yet another exception 2804 is the detection of a duplicatedpayment relative to a particular invoice or relative to a particularvendor, or perhaps due to the failure of the number of payments made toa particular vendor to match a number of invoices received from aparticular vendor. In accordance with aspects of the invention, theseexceptions 2800 are generated by operation of the CORE 160, executingframes reflecting and representing the logic required to review thetransactional entities 2710 and determine exceptions, and createexception entries for storage in the exceptions database 185.

In accordance with aspects of the invention, the illustrative exceptions2800 are shown with an identifier and/or description of the nature ofthe exception, the time, actor identification, and status. Furtherexplanation of the nature of indicators, status, and other aspects ofstored exceptions are described elsewhere herein.

FIG. 29 illustrates an exemplary computer-executable policy statement inthe form of a frame 2900 that is executed by the CORE 160 for reflectingand representing a particular enterprise policy, operative to providepredetermined indicators signaling or representing a possible detectedpolicy violations and to generate one or more exceptions correspondingthereto. The exemplary frame 2900 relates to creation of a “ghostvendor.” Those skilled in the art of financial transaction systems willunderstand that a ghost vendor is a situation where an employee or otherknown person identifies himself or herself as a vendor within theaccounts payable portion of the ERP system. By way of example, anenterprise policy could be established that no employees or otherpersons known to the enterprise can be identified as vendors to receivepayments outside of the payroll system, or that such payments cannot bemade without additional controls or safeguards such as approval of asupervisor, creation of an auditable record, or other financial systemsafeguards.

In accordance with aspects of the invention, frames in the presentinvention are implemented as XML code, which those skilled in the artwill understand is a computer programming expression methodology that iscomputer-executable by a number of different commercially-available XMLprocessing engines that can be utilized in constructing embodiments ofthe present invention. As will be known to those skilled in the art, XMLstands for eXtensible Markup Language and bears certain similarities tothe well known hypertext markup language (HTML). The XML language isdesigned to describe data itself and attributes thereof, and has a knownstructure having “tags”, document type definition portions (DTD), and anXML schema. Each logical expression, statement, attribute, or otheridentifier in an XML document is delimited by a starting tag in theformat of “<tag>” and concludes with a closing tag in the format of“</tag>”. The information between the starting tag and closing tag setsforth a statement, attribute, description, computer command, formula, orother information that can be parsed by an XML interpreter and executedby a computer.

As those skilled in the art will understand how to construct statementsand frames using XML, no further discussion of the particularimplementation methodology using XML will be provided herein.

It should, however, be understood that other computer-implementedmechanisms, languages, scripting methodologies, program modules, and/ordevices could be employed in constructing embodiments of the presentinvention to express enterprise policies in other forms of policystatements, access information in the monitoring database, apply therules of such policy statements, determine exceptions, etc, so as toidentify and determine exceptions and store them in the exceptiondatabase.

The exemplary frame of FIG. 29 illustrates the simple logicalproposition that “if a vendor is an employee, indicate an exception.” Inaccordance with this exemplary policy statement, the frame will indicatean exception in the event that a vendor in the enterprise's accountspayable system and an employee within the enterprise have the sametelephone number. It will, of course, be understood and appreciated thatmany different mechanisms may be used to determine if a vendor is anemployee of the enterprise, and that the example provided is merelyillustrative and not meant to be limiting. Other indicators of theidentity between the vendor and an employee could be reflected by vendorand employee address information, tax ID and/or social securityinformation, bank account number, or other information.

In accordance with aspects of the inventions, each frame such as theexemplary frame 2900 processes data identified in terms of theenterprise ontology, as stored in the knowledge base, with respect toentities that are monitored in the present invention, and determinesindicators based on the processing of data on the monitoring database.In the example of FIG. 29, two separate transactional entities arerequired: a vendor entity identified by the <name> tag AP_VENDOR, and anemployee entity identified by the <name> tag HR_EMPLOYEE, as suchentities are identified in the monitoring database. Such entities, aswill be recalled from previous discussions, are static entities inaccordance with aspects of the invention, and serve as support entitiesfor the logic of this particular frame. The corresponding indicator inthe example is that the vendor and employee have the same telephonenumber, as reflected by the <summary> tag 2910, which describes thepolicy in human-readable form as a comment. The <indicator> tag 2950sets forth the logical computer-executable expression of the data itemsrequired from the monitoring database.

The logical expression that would detect whether the vendor telephonenumber is the same as the employee telephone number is set forth in the<expression> tag within the <indicator> tag. In response to thedetection that a vendor telephone number is the same as an employeetelephone number, a new exception is generated. According to aspects ofthe invention described elsewhere, the new exception comprises a newdata record for storage in the exceptions database 185. The CORE processgenerates the exception and provides information needed to create theexception record including an exception ID, a name, the identities ofall related transactional and support entities, a confidence calculation(if employed). Specific details of the exception are provide inconnection with FIG. 33.

In connection with executing the exemplary frame 2900, an impactparameter may be provided. In accordance with aspects of the invention,the impact parameter is a predetermined amount that reflects ananticipated or expect financial impact or effect of the indicator. Thisimpact may be the particular hard dollar amount associated with thetransaction, if a transaction has an amount, or may be an arbitraryvalue. The impact value facilitates prioritizing the exception. Theexemplary impact in FIG. 29 is 9000.

Each frame typically includes one or more transaction tags. Theseidentify particular transactional entities involved in the frameexecution. In the example of FIG. 29, this transaction tag is AP_VENDOR,which reflects that the frame is executing in response to adetermination that a change was made to data corresponding with a vendorentity.

Each frame typically includes one or more entity tags, e.g. the entitytag in FIG. 29 is HR_EMPLOYEE. Entity tags identify support entitiesthat are involved in evaluating and resolving the logic of the frame todetermine exceptions.

Each frame typically involves one or more indicator tags, e.g. FIG. 29illustrates an indicator having the summary tag <summary> The Vendor andEmployee have the same phone number.</summary>. This summary tag isfollowed by a description tag that accompanies the indicator in theexception record if the indicator resolves to a true condition.

The indicator typically includes one or more logical expressions,identified by the <expr> tag, which contains a logical expression of acondition that if satisfied indicates an exception. The exemplaryexpression FIG. 29 is <expr> VENDOR.PHONE!=‘’ andVENDOR.PHONE=EMPL.PHONE</expr>. This statement reflects that a vendor'stelephone number is not a null value and that the vendor's telephonenumber is equal to the telephone number of the supporting employeeentity that is referred to in the frame.

The indicator typically includes a confidence value, identified by a tag<conf>, which is an arbitrary number or probability that the associatedindicator is revealing a compliance policy violation. The example inFIG. 29 is a confidence value of 0.2. In accordance with other aspectsof the invention, the confidence value is mathematically combined withconfidence values of other associated indicators, and if a cumulativeconfidence value exceeds a predetermined threshold, an exception isindicated.

A frame typically includes one or more <cev> tags, which represents theterm “comprehensive exception view”. This information is provided withan exception as information associated with the exception and how todisplay that information to a user. In particular, the <cev> tagprovides information that enables the frame of FIG. 29 to displayinformation about the vendor entity and the employee entity in a tabularformat.

In accordance with other aspects of the invention, a plurality ofdifferent indicators and frames can execute to determine more complexscenarios, to thereby obtain a greater certainty in establishing acompliance policy violation. In the example of FIG. 29, the mere factthat a vendor and an employee have the same telephone number may not bedispositive of the fact that a vendor is an employee. For example, theexemplary <conf> tag of 0.20 in FIG. 29 is a relatively small confidenceindicator if taken alone. But if the confidence value or indicator of0.20 is combined with other confidence indicators of similar value,resultant from satisfaction of expressions associated with otherindicators in the frame, or from execution of other frames setting forthother tests for “vendor is employee” such as an address match, thecumulated value may add up to a sufficient total value that indicates asufficiently high confidence level that a vendor is truly an employee.

For example, if the vendor telephone number and employee telephonenumber are found to be the same (with confidence value of 0.20), and therespective tax ID (e.g. social security numbers) are found to be thesame (with confidence value of 0.20), and addresses are found to be thesame (with confidence value of 0.20), and a number of payments have beenfound to be the same (with confidence value of 0.20), a cumulativeconfidence factor of 0.80 may result (assuming simple accumulation). Bycomparing the cumulative confidence level to a predetermined value suchas 0.75, as reflected by another frame that executes in conjunction withthe frame 2300, a more complex logical expression may be constructed soas to provide for a number of different logical, financial, and otherchecks to reflect and represent enterprise policy.

As described elsewhere herein, the confidence values are preferablycombined in a statistically appropriate manner rather than simpleaccumulation as describe above. See the discussion in connection withFIG. 32. Note that it is also possible to specify a negative confidencefor an indicator. If such an indicator is true, the total confidence forthe entire exception is reduced rather than increased.

FIG. 30 illustrates details of other indicators used in an exemplaryframe, and different confidence levels associated with the differentindicators. Consider the example of an exception that would be triggeredin the event that two separate vouchers in an accounts payable systemreference the same or a similarly numbered invoice (which might beevidence of a double payment situation, either an error or deliberatefraud). In the example shown, a first indicator 3005 tests for acondition that two different vouchers (exemplary transactions) referencethe same invoice number. This indicator, if resolved to true, possessesa confidence value of 0.3, shown at 3010. A second indicator 3015 testsfor a condition that two different voucher numbers are similar, e.g. thenumbers are the same except for a transposition error in the numerals,or the last digits of the number are within a range of plus or minus 10.This indicator, if resolved to true, possesses a confidence value of0.2, shown at 3020, indicating that the risk of an issue with invoicenumbers being similar is slightly less than the quantified risk ofinvoice numbers being exactly the same.

FIG. 31 illustrates aspects of frame types and execution sequence inaccordance with aspects of the present inventions. In accordance withone aspect of the invention, the knowledge base comprises a plurality ofbase frames. Base frames comprise relatively general enterprise policystatements that are applicable to a wide variety of different types ofenterprises with little or no customization. Base frames generateexceptions in typical business-oriented enterprises with conventionalbusiness functions of accounts payable, accounts receivable, humanresources, etc. It will of course be understood and appreciated that theneeds of businesses are not identical, and that certain enterprisepolicies may need to be adjusted, modified, or entirely not implementedfor various reasons. Additionally, there may be instances whereinentirely new and different enterprise policies may need to beimplemented. Custom frames comprise base frames that have been modifiedor customized so as to meet requirements of a particular enterprise, ornew frames that supplement a preexisting set of base frames and expresspolicies not covered by any of the base frames.

In accordance with aspects of the invention, FIG. 31 illustrates a set3100 of predetermined base frames, a set 3130 of custom frames, and asequence or runtime set 3140 of frames, in the order of execution. Inaccordance with aspects of the invention, each frame is preferablyprovided with a tag to indicate at runtime whether a particular frame isto execute or not. In FIG. 31 this is shown as a tag <frame></frame> toindicate that a frame should execute, and a tag <frameoff></frameoff> toindicate that a frame should not execute. For example, a first baseframe 3002 possesses a <frame tag>, while a second base frame 3004possesses a <frameoff> tag.

In like manner, a first custom frame 3112 possesses a <frameoff> tag toindicate that this frame should not run, while a second custom frame3014 possesses a <frame> tag to indicate this frame should run.

At runtime, and as shown at 3140, the preferred CORE process 160retrieves a set of frames from the knowledge base 165 and executes theframes in a predetermined sequence. In the event that a particular frameshould not execute, it would possess a <frameoff> tag. Thus, it will beseen in the runtime sequence at 3140 that base frame 13002 executes,custom frame 2 3114 executes, base frame 3 3106 executes, etc., whileall frames possessing a <frameoff> tag are not executed. In this manner,a predetermined set of base frames may be called and executed, may beselectively turned off, and may be modified so as to reflect particularcircumstances of a particular enterprise and execute in place of adifferent base frame, or new frames may be created, as desired by asystem administrator.

FIG. 32 provides an example of a frame calculation of parameters ofconfidence, wariness, impact, and priority, which are utilized indisclosed aspects of the invention to provide signals as to the probablesignificance of an indicator or exception. Specifically, this figureillustrates the effects of a two-indicator exception, and how theindicators affect the combined confidence level of the exception,increase a wariness parameter associated with an entity, produce aparticular resulting impact, and utilize a resultant priority value.

Consider that a monitoring entity 3202 for a payment was generated inmonitored system. Assume that the vendor associated with the payment isa preexisting support entity having a vendor record 3204, and that thisentity (ID=5678) possesses an initial wariness value of 300 (expressedin arbitrary terms, but perhaps dollars). A payment (transaction 3202)is issued to this vendor in the amount of $1000, which triggers theexecution of a frame 3206 that is intended to test for some conditionrelating payments to vendors (not specifically illustrated). Within thisframe 3206, there exist two indicators related to the vendor (the logicfor which is not shown but assumed), and their confidence values arec1=0.2 and c2=0.3, as shown in the abbreviated frame, respectively. Theconfidence C of this two-indicator exception may be calculated as shownin step 3208:C=1−(1−c1)*(1−c2)=1−(1−0.2)*(1−0.3)=0.44

The priority of the exception is calculated as follows:

-   -   Priority=Impact * Confidence=1000*0.44=440    -   where in this case the impact is the payment amount ($1000) of        the triggering payment entity 3202. The exception has a priority        value of 440, which in this example results from the application        of the confidence level (which may be considered a probability)        to the nominal impact of the transaction (which in this case is        the amount of the transaction, $1000). Since the exception is        related to the vendor, the wariness of this particular vendor is        increased by 440 after this exception is generated. Therefore,        the wariness of the vendor is now increased to 740, the sum of        the initial wariness and the priority, as shown in 3210.

From the foregoing, those skilled in the art now understand how todetermine various types of indicators, exceptions, wariness, confidence,impact, and priority in accordance with the present invention for manydifferent types of transactions, not just financial transactions.

FIG. 33 illustrates a data schema for an exception, as stored in theexceptions database 185, in accordance with aspects of the presentinvention. An exception is a data structure that contains a number ofdata fields or items, with each field having a type and default value.Data items that represent an exception in the invention include anidentifier (EXCEPTION_ID), a name (EXCEPTION_NAME), informationidentifying the frame that generated the exception and its version

-   (EXCEPTION_FRAME_NAME, EXCEPTION_FRAME_VERSION,    EXCEPTION_FRAME_UPDATE), a description of the exception    (EXCEPTION_DESCRIPTION), a date the exception was detected    (EXCEPTION_DATE_DETECTED), a potential impact    (EXCEPTION_POTENTIAL_IMPACT), an expected impact    (EXCEPTION_EXPECTED_IMPACT), a probability (EXCEPTION_PROBABILITY),    whether or not the exception is marked private by a user    (EXCEPTION_PRIVATE), an owner (EXCEPTION_OWNER), a status field    (EXCEPTION_STATUS_ID), an added by field to indicate an author    (EXCEPTION_ADDED_BY), a category identifier (CATEGORY_ID, a system    identifier (SYSTEM_ID, and a last update time (LAST_UPDATE_TIME).    Other data items may occur to those skilled in the art.

FIG. 34 illustrates relationships between transactional entities andsupport entities, related entities, and exemplary exceptions that aredependent. Assume in this figure that a first transaction (step 1) isthe creation of a new vendor at 3402 in an ERP accounts payable system.This initially is a transactional entity, as shown at 3402. After itscreation, the resultant vendor entity at 3408 is a support entity.Assume that this initial vendor creation transaction was reviewed by aframe designed to determine if any newly created vendor is an employeeof the enterprise (step 2), e.g. “Vendor—Employee Similar”.

Assume now that the “Vendor—Employee Similar” frame determined that someaspects of the newly created vendor and an employee of the enterprisewere similar, for example, the addresses of the two entities are thesame. According to the logic of the frame, this creates an exception3414 (step 3), “Vendor—Employee Similar”. As discussed above inconnection with frames, this exception will have an associatedconfidence level.

Assume next that a purchase order is generated at 3404. This creates atransactional entity, which is related to (connected) to the vendorcreated at step 1. Assume another frame that is designed to examinepurchase orders to determine if any vendors associated with a purchaseorder already are connected to any exceptions (step 4). According to thelogic of this second frame (or another indicator in the first frame),another exception 3416 is created (step 5). This exception is describedas “Suspected Ghost Vendor,” and will also have an associated confidencelevel.

Assume next that a frame or indicator determines that no other employeeswithin the company other than a single employee have ever bought fromthe vendor 3408, i.e. there is a sole buyer 3410 in the system'sdatabase associated with this particular vendor. The fact that only asingle person within the organization has ever bought from thisparticular vendor indicates that the vendor is very new, very small, orvery suspicious. Assume that an indicator of “sole buyer” increases theconfidence level associated with the exception 3416 of “Suspected GhostVendor” (step 6). In accordance with aspects of the invention, theexception 4016 receives an incremental boost to its existing confidencelevel.

Assume next that a frame or indicator is operative upon additional datafrom additional data sources, for example, the system authenticationfunction of the enterprise's IT infrastructure. As shown in FIG. 1,additional information can be extracted and utilized in evaluatingpolicy statements and determining exceptions or parameters associatedtherewith. Assume that such a frame or indicator determines that aparticular user entity 3412 that has logged into the enterprise'ssystems, as reflected by records provided additional IT infrastructuredata sources, is the same user that (a) created the vendor 3408, (b) isthe employee 3406, and (c) is the sole buyer for that vendor (step 7).According to the operation of the indicators that detect suchoccurrences, all of such conditions increase the confidence level ofexception 3416 further still (step 8). In this example, a number ofdifferent but related factors, utilizing different support entities,have affected the confidence level of a policy violation that a “ghostvendor” set up by an employee may be about to receive a paymentindicated by a fraudulent purchase order.

The foregoing has illustrated a number of different aspects ofindicators, frame execution, increase of confidence level, exceptions,transactional and support entities, and the like, and demonstrates tothose skilled in the art that systems and methods of the presentinvention may be adapted to address myriads of enterprise compliancepolicy situations.

Exception Management and Reporting

As shown in FIG. 1, exceptions from operations of the CORE process 160are stored in an exceptions database 185. A case management system 190comprising a an analysis and reporting user interface 180 handlesexceptions and cases involving one or more exceptions, for compliancepolicy management and reporting functions. Thee analysis and reportinguser interface 180 provides information to users 101 and facilitatesreview, inspection, management, reporting, and other functions forhandling reported exceptions from the system.

From the discussion above, it will be understood that the CORE 160 isoperative to executive frames from the knowledge base on the monitoringdatabase 175 and to generate one or more exceptions that arerepresentative of the violation or possible violation of enterprisepolicies. Exceptions take the form of data items generated by the CORE160. Principally, each exception data item includes informationreflecting the nature of the exception as determined by particular framethat generated the exception, time information, actor identificationinformation, and a status indicator. The case management system 190provides analysis of exceptions and reporting of exceptions, so as tofacilitate the provision of information to users regarding generatedexceptions, to provide a mechanism for storing collections ofexceptions, and to manage investigations in the form of a case. A casetypically comprises a plurality of exceptions with status relating tosuch exceptions, to permit the enterprise to monitor and control itsbusiness processes.

In accordance with aspects of the invention, the case management system190 is a computer-implemented process that retrieves information fromthe exceptions database 185 and the monitoring database 175 and presentsthe information to users, e.g., users 101 as shown in FIG. 1, in variousmanners. The analysis and reporting component 180 of the case managementsystem 190 results provides a display of various user interface screensso as to display information regarding exceptions and entities to users,and to receive control information from users for purposes of assigningpersonnel as case managers or investigators, changing the status ofitems, and collecting other information (clues) that may be relevant toan investigation of one or more exceptions constituting a case, forreporting and other purposes.

There are three major aspects to the analysis component of the casemanagement system of the invention. The first is a set of detaileddisplays of exceptions including an exception summary list, and for eachexception an automatically generated natural language description,several detailed views of the entities underlying the exception, and adisplay for various other parameters describing the exception. Thesecond is a similar display for entities, which displays a summary listof entities optionally sorted by their composite wariness score, and adetailed view for an entity including a display for all the exceptionsthat the entity supports as well as a display for various attributes ofthe entity. The third is a user-configurable summary display thatdisplays aggregate statistics for exceptions and entities, graphs, andalerts.

FIG. 35 illustrates an exemplary exceptions display user interface (UI)screen 3500 that shows exceptions displayed to a user. An exceptionsdisplay control 3502 is shown activated, which results in display of aplurality of exceptions in a list at the top of the screen. Eachexception is identified by an exception ID, a name of the exception, apriority, and an owner. An exemplary exception,VOUCHER_LINE_DUPLICATE_AMOUNT-1053020000364 is shown as selected by theuser. This particular exception, it will be understood, necessarilyinvolves two separate vouchers (two separate entities) whose amounts areidentical, i.e. $68,104.00. The entities involved in this exception areshown in a region of “related entities,” two in the present example,entity 3510 and 3512.

The Entities tab in the lower display region is shown selected, whichcauses display of information associated with the entities that wereinvolved in triggering the exception of duplicate vouchers with the sameamount. A description field 3515 shows information associated with theexception, and identifies the indicators that triggered the exception,e.g. that “Exactly two VoucherLines were entered for the same Vendor forthe same amount within 14 days.” This information is provided from thedescription information in the exception data record, as describedabove.

Note that a popup control (effective on a right click in embodiments ofthe invention) is shown at 3506. Assume that the cursor was positionedover the Voucher ID data field. Assume that the user selects the command“Show Related Entity” at 3508. In accordance with aspects of theinvention, this will cause display of entities that are related to theparticular voucher, for example, an associated purchase order (PO).

Turn in this regard to FIG. 36 for an illustration of an exemplaryrelated entities display user interface (UI) screen 3600 that shows anentity or entities related to an entity that is the subject of anexception, in particular the exception and entities of FIG. 35. Notethat the Related Entities control 3602 is shown highlighted as havingbeen selected or activated. The Summary tab 3610 is shown selected,which results in display of information corresponding to an entity (aparticular purchase order with Entity ID 00100-OP-11648-000-200). As canbe seen, information about the purchase order transactional entityassociated with the previous duplicate vouchers is displayed for userassessment, such as PO line ID, PO ID, a Vendor ID, and QuantityOrdered. In accordance with aspects of the invention, a user can selectentities that are related to particular entities that triggerexceptions, and view the information. This connection ability isreferred to in the invention as “linking” to associated or relatedentities.

FIG. 37 is an illustration of an exemplary detailed display ofinformation about related entities in a user interface (UI) screenassociated with the analysis and reporting UI 180. In this illustration,detailed information about one or more entities involved in an exceptionare displayed. This display is generated in preferred embodiments of theinvention in response to user activation of the exception 3504 asdisplayed in the list of exceptions in FIG. 35, for example bydouble-clicking on the particular exception. In particular, this displayallows side-by-side comparison of the details of two different vouchersthat were indicated as “duplicate,” so that a user can inspect theinformation corresponding to the entities involved, and determine adisposition of the exception, assign it to a case for investigation,etc.

FIG. 38 is an illustration of an exemplary display of information aboutrelated entities in a user interface (UI) screen associated with theanalysis and reporting UI 180, where the entities are provided fromdifferent data sources. This is an example of link analysis provided inaspects of the invention. This display illustrates the ability ofsystems constructed in accordance with the invention to bring togetherinformation from disparate, even heterogeneous data sources, connectinformation by way of indicators and exceptions, and facilitate ananalysis and investigation of transactions that give rise to policystatement exceptions. In the example of FIG. 38, an exception identifiedas PO_TO_GHOST_VENDOR is identified as an exception that is to beinspected and analyzed. In this example, a transactional entity of apurchase order has been issued to a support entity that was previouslydetermined, by another exception, to have a certain confidence level ofbeing a “ghost vendor.” The information displayed in this figure aboutrelated entities is, logically, information about the purchase ordertransactional entity (shown at 3810) and information about the vendorpreviously identified as a ghost vendor (shown at 3815). Note in theDescription of Exceptions display area 3820 that two indicators underlieor are associated with the exception: “PO issued to Vendor flagged asghost” (and an associated exception identifier) and “Only one Buyer(MRO) purchased from the Vendor: increases confidence”.

As another example of link analysis provided in aspects of theinvention, FIG. 39 is an illustration of an exemplary display ofinformation about other related entities in a user interface (UI) screenassociated with the analysis and reporting UI 180, where the entitiesare provided from different data sources, in this case vendorinformation from an accounts payable system at 3910 and informationabout a particular employee from an human resources (HR) system at 3915.This display screen shows the entities involved in an exception,discussed above, where a vendor and an employee were determined to havea similar or identical address. Indicators of this exception are shownat 3920.

Case Management and Reporting

FIG. 40 is an illustration of an exemplary case management userinterface (UI) display screen associated with the analysis and reportingUI 180. This display is generated for users that have a number ofexceptions assigned to them for handling and/or investigation and/ordisposition. As in previous displays, a region 4000 is provided for adisplay of a number of exceptions, by ID, name, priority, owner, etc. Aparticular exception, GHOST_VENDOR-105302000364, is shown highlighted ashaving been selected by a user. The summary tab in a display region 4010provides a display of particular information associated with theselected exception. In this case, information associated with the “ghostvendor” exception includes the exception name at 4002, a priority 4003,a potential impact 4004, a case manager assigned to the exception 4005,a confidence value 4006, and status information 4007, e.g. “UnderReview.” Other information such as secondary case managers 4012 areshown, as well as a scheme display and system display (e.g. AP foraccounts payable). Also included is information about the case ID, datecreated, and date modified. Also included is checkbox 4013 for markingthe selected exception as “private” so that unauthorized users will nothave access to the exception.

FIG. 41 illustrates an exemplary case management UI screen 4100, withthe Entities tab selected. This screen illustrates a collection ofinformation relating to a particular actor, in this example an employee“Adelbert Bell,” whose name is displayed in a data display field 4102.Display area 4104 includes other information relating to the particularactor, who in this case may be considered a subject under investigation,for example, the employee ID, last name, first name, SSN, address, etc.A Case ID and Date Created display area is also provided. It will beunderstood that the information provided when the Entities tab isselected is particular to and dependent on the nature of the particularentity. In this case, an employee entity (a static support entity,likely from an HR system) is displayed.

FIG. 42 illustrates an exemplary case management user interface screen4200, with the Chronology tab selected. According to aspects of theinvention, a graphical display of one or more exceptions is presented ina timeline format, together with other useful information. The disclosedsystem generates a timeline that displays exceptions along the timeline,in association with particular transactions that relate to theexceptions. The displayed exception information includes a labelidentifying the nature of the exception and a date and time. Icons orother symbols reflecting disposition of the exception or status may alsobe provided.

In the screen 4200, a number of particular transactions relating toexceptions are displayed, to illustrate certain linking functions ofcertain aspects of the present invention. According to such aspects ofthe invention, a collection of transactions related to particular actorsor to particular static entities are collected and displayed in atimeline chronology. In the example of FIG. 42, specific transactionsare illustrated as an unfilled circle, e.g., transactions 4201, 4203,4207, 4211, 4217. Exceptions and detections thereof are indicated as afilled-in circle, e.g., 4205, 4209, 4213, and 4219.

For example, the transaction 4201 relates to the creation of a vendoridentified as AA, while transaction 4203 represents the creation of asecond vendor identified as ABBC. In the example illustrated, assumedthat the two transactions 4201, 4203 resulted in the utilization of thesame address for two different vendors. Assume further that a policyframe is provided to determine whether duplicate addresses exists fordifferent vendors, and generate an exception as a result the processingof an appropriate frame. This would be indicated at as the exception3505 in the chronology, “Opportunity Exception (Duplicated Address)”,together with a date and time of detection, and displayed with thefilled-in circle icon.

Advantageously, the different display techniques allow users to readilyidentify and analyze exceptions and their related transactions, andgraphically display the relationships between various occurrences oftransactions and exceptions over time.

Another example of a detected exception is shown at 4213, identified as“Ghost Vendor Scheme Detected.” A predetermined display indicator 4215is provided to indicate that supervisory personnel or auditor have beennotified regarding the exceptions.

FIG. 43 illustrates an exemplary case management user interface screen4200 with a Reports tab selected. This particular display screenincludes a subsidiary display screen 4305 with subsidiary tabs Impact,Confidence, and Status. The Impact subtab is shown selected. In thisparticular view, information relating to particular case numbersassigned to a particular user (case manager) are displayed in a tableformat including a Case No. column indicating case numbers assigned toparticular case, an Exception ID column identifying exceptionsassociated with the various cases, an Actor column for identifyingactors (e.g. certain individuals) that are or might be consideredsubjects, an Exception Description column displaying identifyinginformation relating to particular cases under investigation, and anImpact column displaying a computed impact of a particular case and theexceptions represented thereby. The manner of computing impact has beendescribe elsewhere herein.

According to aspects of the invention, the Impacts column is cumulatedto form a total, as indicated in by the Total display area 4306.

Selector buttons are also provided so as to allow cumulating thecalculated impact(s) for a predetermined time intervals, e.g., Date,Week, Month, Year. The Month selector is activated at 4302, indicatingthat the cumulated total impact of the exceptions assigned to thisparticular user represents the impact for the particular month inquestion.

FIG. 44 illustrates an exemplary case management user interface screen4400 with the Status subsidiary tab selected. In this particulardisplay, a user may activate a selector box to select a collection ofcases that have similar status assigned and view information relating toexceptions and their calculated potential impact. Otherwise the view issimilar to that of FIG. 43. Case statuses provided in the describedembodiment of the present invention include Detected, Under Review,Dismissed, and Fixed. In the example shown in the FIG. 44, the UnderReview selector box 4401 has been actuated, so as to cause display of aplurality of cases having this status assigned. Accordingly, thecumulative impact in the Total field 4406 reflects the added impact ofall cases displayed that are considered “under review” in the system andhaving been assigned to a particular user.

FIG. 45 illustrates an exemplary case management user interface screenthat allows assignment of an exception to a particular user asinvestigator or case manager. A particular exception 4504 is shownselected, identified as VOUCHER_LINE_TO_DUPLICATE_PO-10503200000793. TheSummary tab is shown selected. The display area associated with theSummary tab shows a number of data items or fields associated with thisexception, including the Exception ID, Owner 4506, Status 4508, Priority(calculated as described elsewhere), Confidence (as describedelsewhere), Category, System, Potential Impact (as described elsewhere).In particular, the Owner field control is shown actuated, whichgenerates a pulldown or popup selector box 4506 having a list of namesof users that can be selected to assign such persons as Owner of theparticular exception. This assignment function would typically beimplemented as a function of an administrative level person.

FIG. 46 is an exemplary case management user interface screen 4600 withthe Notes tab selected. The region 4601 provides an area for user inputof notes relating to particular cases being handled by a particularauthorized person who is reviewing and inspecting the screen.

FIG. 47 is an exemplary case management user interface screen 4700 withLog tab selected. This particular display screen includes a displayregion 4702 for display of information relating to a log of informationas to the handling of particular actors, exceptions, or the handlingthereof.

In order to illustrate certain principles involves in the disclosedembodiments and aspects of the present invention turn to FIG. 48 for anillustration of an exemplary exception and various steps in thedetection and reporting of the exception. The exemplary exception takesthe form of an employee changing the bank account number for aparticular vendor to substitute his or her bank account for the vendor'sbank account, perhaps as a part of a fraudulent scheme to steal fundsfrom the enterprise. In accordance with aspects of the invention, assumethat the enterprise maintains a compliance policy frame or statementoperative to detect whether a vendor's bank account number is the sameas an employee's bank account number. Accordingly, the change of avendor's bank account number will constitute a transaction monitored bythe TIM system 100; this can be indicated by operation of a framesimilar to that described above in connection the “Ghost Vendor”situation described above, except containing expressions designed tocompare vendor bank account numbers with employee bank account number.

The various steps of interest in the exception processing are identifiedas numbers within circles, reflecting steps 1-9 of a process foridentifying a Ghost Vendor exception and establishing a case to handlethe determination of the exception. At step 1, assume that an employee(actor) 102 of the enterprise changes the bank account number of aparticular vendor ID 1234 from 5678 to account number 8899. The datarelating to this change will be stored in the ERP database 120, and inparticular in the vendor table 4815.

At step 2, a transaction containing the information relating to thischange is acquired by the extractor 140 in accordance with aspects ofthe present invention. Assume that information indicating changes toentities is provided in the form of an audit log, stored in an audit logtable 4817 in the ERP database. An audit or transaction log data item4801 is provided to the data extractor 140 via the audit/transactionlog. At step 3 the extractor 40 queries the ERP database 120 to retrieveother information (related entity information) regarding Vendor 1234, inaccordance with the extractor information. At step 4, other informationfrom the query back to the ERP database is provided, including the newbank account number for Vendor 1234.

At step 5, a corresponding monitoring entity 4803 is created in themonitoring database 175. At step 6, a frame 4805 reflecting anenterprise policy is retrieved from the knowledge base 165 and providedto the CORE 160. Assume that the frame 4805 expresses the policy that anexception should be indicated if a vendor bank account number is thesame as an employee bank account number. At step 6, the CORE 160determines from execution of the frame 4805 that an exception hasoccurred, and stores an exception entry 4810 in the exceptions database185.

At step 7, the case management process 190 retrieves (or is provided)the exception and generates a case report indicating that a Ghost Vendorexception has been determined, with provision of information relating toimpact and confidence level. At step 8, information relating to theGhost Vendor exception is displayed to a user 101 via the casemanagement/analysis and report UI 180. At step 9, optionally, theextractor retrieves additional information relating to vendor 1234 fromthe ERP database in a subsequent extraction operation (e.g. from accessto external data sources 131), so as to obtain further details aboutvendor 1234 or about the employee, for use in connection with a case orinvestigation.

The foregoing description of the exemplary embodiments of the inventionshas been presented only for the purposes of illustration and descriptionand is not intended to be exhaustive or to limit the invention to theprecise forms disclosed. Many modifications and variations are possiblein light of the above teachings.

Others Aspects of the Inventions

The follow are additional aspects and statements of the inventions.

Aspect 1 (Extraction): Methods and Systems for Extraction of TransactionData for Compliance Monitoring

1. A system for extracting data relating to transactions from one ormore external data sources and for providing data for use by atransaction analysis engine operative for executing one or morecomputer-executable compliance policy statements against extracted data,comprising:

-   -   a data communications port coupled to one or more data sources;    -   a master extractor program module operative for extracting an        initial selected subset of information about monitored        transactions from one or more data sources;    -   a log extractor program module operative for extracting        information about monitored transactions from a log file        provided by one or more data sources;    -   a resync extractor program module operative for extracting        information from one or more data sources from which data was        previously extracted in response to a resynchronize condition;    -   a programmatic extractor program module operative to receive        information provided by programmatic operation of a data source        that conducts data export; and    -   a storage program module for storing extracted information.

2. The system of claim 1, wherein at least one of the data sources is anenterprise system that stores information corresponding to enterprisedata transactions.

3. The system of claim 2, wherein the data sources comprise a pluralityof heterogeneous databases that store information relating to businesstransactions of the enterprise.

4. The system of claim 2, further comprising an external data sourceextractor program module for obtaining information relating totransactions from one or more data sources external to the enterprisesystem.

5. The system of claim 1, wherein the storage program module storesextracted information in a monitoring database.

6. The system of claim 5, wherein the storage program module storesextracted information in a staging database, and a mapper program modulestores the extracted information in the monitoring database according toan enterprise ontology.

7. The system of claim 1, further comprising an extractor file foridentifying each data source and information required to access data inthe data sources.

8. The system of claim 7, wherein the extractor file providesinformation identifying a source table, predetermined fields of thesource table, a destination table, and predetermined fields in thedestination table in which the source table fields are stored.

9. The system of claim 1, wherein the data sources include one or moreadditional data sources that provide information supplemental to themonitored transactions.

10. The system of claim 9, wherein the additional data sources includean information technology (IT) system infrastructure equipment thatprovides data corresponding to IT system utilization.

11. The system of claim 10, wherein the IT system infrastructureequipment is selected from the group: file server, application server,firewall, router, intrusion detection equipment, authentication server.

12. The system of claim 9, wherein the additional data sources includean external data source that provides data ancillary to a particularmonitored transaction.

13. A method for extracting data relating to transactions from one ormore external data sources and for providing data for use by atransaction analysis engine operative for executing one or morecomputer-executable compliance policy statements against extracted data,comprising the steps of:

-   -   extracting an initial selected subset of information about        monitored transactions from one or more data sources;    -   extracting information about monitored transactions from a log        file provided by one or more data sources;    -   extracting information from one or more data sources from which        information was previously extracted to resynchronize data in        response to a resynchronization condition;    -   receiving information provided by programmatic operation of a        data source that conducts data export; and    -   storing extracted information for access by the transaction        analysis engine.

14. The method of claim 13, wherein at least one of the data sources isan enterprise system that stores information corresponding to enterprisedata transactions.

15. The method of claim 14, wherein the data sources comprise aplurality of heterogeneous databases that store information relating tobusiness transactions of the enterprise.

16. The method of claim 14, further comprising the step of obtaininginformation relating to transactions from one or more data sourcesexternal to the enterprise system.

17. The method of claim 13, wherein the storage program module storesextracted information in a monitoring database.

18. The method of claim 17, wherein step of storing extractedinformation comprising storing in a staging database to minimize thecomputational load on the data source, and further comprising the stepsof retrieving the information from the staging database and storing theextracted information in the monitoring database according to anenterprise ontology.

19. The method of claim 13, further comprising the step of identifyingeach data source and information required to access data in the datasources in an extractor file.

20. The method of claim 19, wherein the extractor file providesinformation identifying a source table, predetermined fields of thesource table, a destination table, and predetermined fields in thedestination table in which the source table fields are stored.

21. The method of claim 13, wherein the data sources include one or moreadditional data sources that provide information supplemental to themonitored transactions.

22. The method of claim 21, wherein the additional data sources includean information technology (IT) system infrastructure equipment thatprovides data corresponding to IT system utilization.

23. The method of claim 22, wherein the IT system infrastructureequipment is selected from the group: file server, application server,firewall, router, intrusion detection equipment, authentication server.

24. The method of claim 21, wherein the additional data sources includean external data source that provides data ancillary to a particularmonitored transaction.

25. A system for monitoring transactions of an enterprise stored in oneor more enterprise systems associated with an enterprise, thetransactions corresponding to one or more business transactions of theenterprise, to determine possible lack of compliance of a businesstransaction with one or more predetermined policies of the enterprise,comprising:

-   -   an extractor for extracting an initial selected subset of        information about monitored transactions from an enterprise        system;    -   a second extractor, responsive to changed data in the enterprise        system, for extracting a second selected subset of information        about the changed data;    -   a monitoring database for storing the initial subset of        information and the second subset of information as monitoring        entities;    -   a transaction analysis engine for executing one or more        computer-executable policy statements against the monitoring        database; and    -   a user interface, responsive to a determination from execution        of a policy statement of an exception to a predetermined policy        for providing an output corresponding to the exception        indicating a possible lack of compliance with the predetermined        policy.

26. The system of claim 25, wherein the selected subsets of informationcorrespond to a predetermined selection of data fields from apredetermined selection of database tables storing businesstransactions.

27. The system of claim 25, wherein the initial selected subset ofinformation from the enterprise system comprises informationcorresponding to a complete set of business transactions current througha predetermined date.

28. The system of claim 27, wherein the second selected subset ofinformation from the enterprise system comprises informationcorresponding to business transaction changes occurring subsequent tothe predetermined date.

29. The system of claim 25, wherein the policy statements comprisecomputer-executable expressions of relationships between predetermineddata items in the monitoring database, expressed in terms of anenterprise ontology, that resolve into indicators that determineexceptions.

30. The system of claim 25, wherein the extractors refer to storedextractor information identifying one or more data sources, accessinformation for the data sources, selected data tables in the datasources, and selected fields in the selected tables.

31. The system of claim 25, wherein the extractors comprise computerprogram modules providing for a master extraction, a log extractor, aprogrammatic extractor, a resync extractor, an external data sourceextractor, and an information technology (IT) system extractor.

32. The system of claim 25, further comprising one or more additionaldata sources that provide information supplemental to the monitoredtransactions.

33. The system of claim 32, wherein the additional data sources includean information technology (IT) system infrastructure equipment thatprovides data corresponding to IT system utilization.

34. The system of claim 33, wherein the IT system infrastructureequipment is selected from the group: file server, application server,firewall, router, intrusion detection equipment, authentication server.

35. The system of claim 32, wherein the additional data sources includean external data source that provides data ancillary to a particularmonitored transaction.

36. A computer-implemented method for monitoring transactions of anenterprise stored in one or more enterprise systems associated with anenterprise, the transactions corresponding to one or more businesstransactions of the enterprise, to determine possible lack of complianceof a business transaction with one or more predetermined policies of theenterprise, comprising the steps of:

-   -   extracting an initial selected subset of information about        monitored transactions from an enterprise system;    -   storing the initial subset of information in a monitoring        database as a monitoring entity;    -   thereafter, in response to changed data in the enterprise        system, extracting a second selected subset of information about        the changed data;    -   storing the second subset of information in the monitoring        database as a monitoring entity;    -   executing one or more computer-executable policy statements from        a knowledge base against the monitoring database; and    -   in response to the determination from the execution of a policy        statement of an exception to a predetermined policy, providing        an output corresponding to an exception indicating a possible        lack of compliance with the predetermined policy.

37. The method of claim 36, wherein the selected subsets of informationcorrespond to a predetermined selection of data fields from apredetermined selection of database tables storing businesstransactions.

38. The method of claim 36, wherein the initial selected subset ofinformation from the enterprise database comprises informationcorresponding to a complete set of business transactions current througha predetermined date.

39. The method of claim 38, wherein the second selected subset ofinformation from the enterprise database comprises informationcorresponding to business transaction changes occurring subsequent tothe predetermined date.

40. The method of claim 36, wherein the policy statements comprisecomputer-executable expressions of relationships between predetermineddata items in the monitoring database, expressed in terms of anenterprise ontology, that resolve into indicators that determineexceptions.

41. The method of claim 36, wherein the extracting steps are effectedwith reference to stored extractor information identifying one or moredata sources, access information for the data sources, selected datatables in the data sources, and selected fields in the selected tables.

42. The method of claim 36, wherein the extracting steps are effectedwith computer program modules for a master extraction, a log extractor,a programmatic extractor, a resync extractor, an external data sourceextractor, and an information technology (IT) system extractor.

43. The method of claim 36, further comprising the step of extractinginformation from one or more additional data sources that provideinformation supplemental to the monitored transactions.

44. The method of claim 43, wherein the additional data sources includean information technology (IT) system infrastructure equipment thatprovides data corresponding to IT system utilization.

45. The method of claim 44, wherein the IT system infrastructureequipment is selected from the group: file server, application server,firewall, router, intrusion detection equipment, authentication server.

46. The method of claim 43, wherein the additional data sources includean external data source that provides data ancillary to a particularmonitored transaction.

Aspect 2 (Mapping into Common Ontology): Methods and Systems for MappingTransaction Data to Common Ontology for Compliance Monitoring

1. A computer-implemented system for transforming information from adata source relating to a transactional entity into a form forprocessing by a transaction analysis engine operative upon dataexpressed in a predetermined ontology, comprising the steps of:

-   -   an input for receiving source data from a data source        corresponding to the transactional entity;    -   a mapping file specifying details of a target schema that maps a        set of data fields from the data source into target data fields        of a data record for a target entity corresponding to the        transactional entity in a monitoring database;    -   a metadata generator for generating predetermined metadata        associated with the transactional entity for storage in        corresponding metadata fields of the target entity data record        in the monitoring database;    -   a program module for transforming the source data in accordance        with the mapping file to obtain corresponding data fields of the        target entity data record; and    -   a storage module operative for storing the transformed source        data and predetermined metadata as a target entity in the        monitoring database in accordance with the mapping file.

2. The system of claim 1, wherein the system comprises computer programcode.

3. The system of claim 1, further comprising a staging database, andwherein the source data is temporarily cached in the staging databaseprior to the transforming operation.

4. The system of claim 3, wherein the staging database stores the sourcedata in a schema corresponding to the schema of the data source.

5. The system of claim 1, further comprising an ontology file providinginformation about entities that are related to the transactional entity.

6. The system of claim 1, wherein the related entities are identified asa function of predetermined data fields common to a data field of thetransactional entity.

7. The system of claim 1, wherein the mapping file is stored in aknowledge base.

8. The system of claim 1, wherein the target entity has at least onedata field that is a function of a plurality of data fields from one ormore data sources, and wherein the mapping file stores information foruse in transforming the plurality of data fields from the one or moredata sources into an appropriate format for the target entity datafield.

9. The system of claim 1, wherein the metadata comprises version dataassociated with the transactional entity, whereby the monitoringdatabase maintains a plurality of versions of the transactional entityover time,

-   -   whereby the occurrence of changes over time to data in the data        source are detected and preserved, so that multiple sequential        versions of particular entities are preserved.

10. The system of claim 1, wherein the metadata includes a timestamp andactor identification information.

11. The system of claim 1, wherein the data source comprises one or moreenterprise systems.

12. The system of claim 11, wherein the enterprise systems comprise aplurality of heterogeneous databases that store information relating tobusiness transactions of an enterprise, in which one or morepredetermined data fields in a first one of the heterogeneous databasescontains information relating to one or more predetermined data fieldsin a second one of the heterogeneous databases,

13. The system of claim 1, further comprising program code forprecomputing predetermined information utilized by the transactionanalysis engine, so as to improve performance of the transactionalanalysis engine.

14. The system of claim 13, wherein the precomputed predeterminedinformation comprises calculations based on a plurality of storedtransactional entities.

15. The system of claim 1, further comprising one or more additionaldata sources that provide information supplemental to the transactionalentity.

16. The system of claim 15, wherein the additional data sources includean information technology (IT) system infrastructure equipment thatprovides data corresponding to IT system utilization.

17. The system of claim 16, wherein the IT system infrastructureequipment is selected from the group: file server, application server,firewall, router, intrusion detection equipment, authentication server.

18. The system of claim 15, wherein the additional data sources includean external data source that provides data ancillary to a particularmonitored transaction.

19. A method for transforming information from a data source relating toa transactional entity into a form for processing by a transactionanalysis engine operative upon data expressed in a predeterminedontology, comprising the steps of:

-   -   retrieving source data from a data source corresponding to the        transactional entity;    -   retrieving a mapping file, the mapping file specifying details        of a target schema that maps a set of data fields from the data        source into target data fields of a data record for a target        entity corresponding to the transactional entity in a monitoring        database;    -   generating predetermined metadata associated with the        transactional entity for storage in corresponding metadata        fields of the target entity data record in the monitoring        database;    -   transforming the source data in accordance with the mapping file        to obtain corresponding data fields of the target entity data        record;    -   storing the transformed source data and predetermined metadata        as a target entity in the monitoring database in accordance with        the mapping file.

20. The method of claim 19, wherein the source data is temporarilycached in a staging database prior to the steps of the method.

21. The method of claim 20, wherein the staging database stores thesource data in a schema corresponding to the schema of the data source.

22. The method of claim 19, further comprising the step of retrieving anontology file prior to the final storing step, the ontology fileproviding information about entities that are related to thetransactional entity.

23. The method of claim 19, wherein the related entities are identifiedas a function of having predetermined data fields common to a data fieldof the transactional entity.

24. The method of claim 19, wherein the mapping file is retrieved from aknowledge base.

25. The method of claim 19, wherein the target entity has at least onedata field that is a function of a plurality of data fields from one ormore data sources, and wherein the mapping file stores information foruse in transforming the plurality of data fields from the one or moredata sources into an appropriate format for the target entity datafield.

26. The method of claim 19, wherein the metadata comprises version dataassociated with the transactional entity, whereby the monitoringdatabase maintains a plurality of versions of the transactional entityover time,

-   -   whereby the occurrence of changes over time to data in the data        source are detected and preserved, so that multiple sequential        versions of particular entities are preserved.

27. The method of claim 19, wherein the metadata includes a timestampand actor identification information.

28. The method of claim 19, wherein the data source comprises one ormore enterprise systems.

29. The method of claim 28, wherein the enterprise systems comprise aplurality of heterogeneous databases that store information relating tobusiness transactions of an enterprise, in which one or morepredetermined data fields in a first one of the heterogeneous databasescontains information relating to one or more predetermined data fieldsin a second one of the heterogeneous databases,

30. The method of claim 19, further comprising the step of precomputingpredetermined information utilized by the transaction analysis engine,so as to improve performance of the transactional analysis engine.

31. The method of claim 30, wherein the precomputed predeterminedinformation comprises calculations based on a plurality of storedtransactional entities.

32. The method of claim 19, further comprising the step of retrievinginformation supplemental to the transactional entity from one or moreadditional data sources.

33. The method of claim 32, wherein the additional data sources includean information technology (IT) system infrastructure equipment thatprovides data corresponding to IT system utilization.

34. The method of claim 33, wherein the IT system infrastructureequipment is selected from the group: file server, application server,firewall, router, intrusion detection equipment, authentication server.

35. The method of claim 32, wherein the additional data sources includean external data source that provides data ancillary to a particularmonitored transaction.

36. A system operative for codifying compliance policies utilizing aunifying ontology for data items corresponding to transactions stored inone or more heterogeneous data sources, comprising:

-   -   a policy statement data store for storing a set of        computer-executable policy statements expressing informational        relationships between data items associated with the        transactions, the policy statements expressed in an enterprise        ontology, the policy statements executable on a monitoring        database;    -   an ontology data store for storing an ontology file expressing        the enterprise ontology for expressing the transforming the        transaction data items to a schema for the monitoring database,        the schema for unifying data items from the heterogeneous        databases; and    -   a mapping data store for storing a mapping file for mapping the        data items to the monitoring database schema in accordance with        the enterprise ontology

37. The system of claim 36, further comprising means responsive to theontology file and mapping file for transforming data items from the datasource into monitoring entities for storing in a monitoring database.

38. The system of claim 36, further comprising a transaction analysisengine for retrieving the computer-executable policy statements from thepolicy statement data store, executing them against the monitoringentities in the monitoring database, and providing an output indicatinga possible lack of compliance of a transaction with one or more of thepolices expressed by the policy statements.

39. The system of claim 38, further comprising an exceptions store forstoring a plurality of exceptions from the transaction analysis engine.

40. The system of claim 38, further comprising a user display fordisplaying a list of a plurality of exceptions that occurred as resultof policy statement execution; and

-   -   in response to user selection of one of the plurality of        exceptions, displaying detailed information about the selected        exception.

41. The system of claim 40, wherein the ontology stores informationrelating a transaction to other entities, and further comprising thestep of displaying information corresponding to one or more entitiesassociated with the exception.

42. The system of claim 36, further comprising a staging database forcaching information received from a data source prior to storage in themonitoring database.

43. The system of claim 36, further comprising a component for addingmetadata to transaction data to form the monitoring entity that isstored in the monitoring database.

44. The system of claim 43, wherein the metadata comprises revisioninformation that allows comparison of different versions of an entityover a period of time,

-   -   whereby changes over time to data in the data source are        detected and preserved, so that multiple sequential versions of        particular monitored entities are preserved.

45. The system of claim 43, wherein the metadata comprises a timestampand actor identification information.

46. The system of claim 36, wherein the data sources include one or moreadditional data sources that provide information supplemental to themonitored transaction data items.

47. The system of claim 46, wherein the additional data sources includean information technology (IT) system infrastructure equipment thatprovides data corresponding to IT system utilization.

48. The system of claim 47, wherein the IT system infrastructureequipment is selected from the group: file server, application server,firewall, router, intrusion detection equipment, authentication server.

49. The system of claim 46, wherein the additional data sources includean external data source that provides data ancillary to a particularmonitored transaction.

50. The system of claim 46, wherein a policy statement is operative oninformation from the additional data sources as well as informationcorresponding to transaction data items.

51. A method for codifying compliance policies utilizing a unifyingontology for data items corresponding to transactions stored in one ormore heterogeneous data sources, comprising the steps of:

-   -   providing a set of computer-executable policy statements        expressing informational relationships between data items        associated with the transactions, the policy statements        expressed in an enterprise ontology, the policy statements        executable on a monitoring database;    -   providing an enterprise ontology for expressing the        transformation of the transaction data items to a schema for the        monitoring database, the schema for unifying data items from the        heterogeneous databases; and    -   providing mapping file for mapping the data items to the        monitoring database schema in accordance with the enterprise        ontology

52. The method of claim 51, further comprising the step of transformingdata items from the data source into monitoring entities for storing inthe monitoring database in accordance with the ontology and mappingfile.

53. The method of claim 51, further comprising the step of retrievingthe computer-executable policy statements from the policy statement datastore, executing them against the monitoring entities in the monitoringdatabase, and providing an output indicating a possible lack ofcompliance of a transaction with one or more of the polices expressed bythe policy statements.

54. The method of claim 53, further comprising the step of storing aplurality of exceptions in an exceptions store.

55. The method of claim 53, further comprising the steps of: displayinga list of a plurality of exceptions that occurred as result of policystatement execution;

-   -   in response to user selection of one of the plurality of        exceptions, displaying detailed information about the selected        exception.

56. The method of claim 55, wherein the ontology stores informationrelating a transaction to other entities, and further comprising thestep of displaying information corresponding to one or more entitiesassociated with the exception.

57. The method of claim 51, further comprising the step of cachinginformation received from a data source prior in a staging databaseprior to storage in the monitoring database.

58. The method of claim 36 further comprising the step of addingmetadata to transaction data to form the monitoring entity that isstored in the monitoring database.

59. The method of claim 58, wherein the metadata comprises revisioninformation that allows comparison of different versions of an entityover a period of time,

-   -   whereby changes over time to data in the data source are        detected and preserved, so that multiple sequential versions of        particular monitored entities are preserved.

60. The method of claim 58, wherein the metadata comprises a timestampand actor identification information.

61. The method of claim 51, wherein the data sources include one or moreadditional data sources that provide information supplemental to themonitored transaction data items.

62. The system of claim 61, wherein the additional data sources includean information technology (IT) system infrastructure equipment thatprovides data corresponding to IT system utilization.

63. The system of claim 62, wherein the IT system infrastructureequipment is selected from the group: file server, application server,firewall, router, intrusion detection equipment, authentication server.

64. The system of claim 61, wherein the additional data sources includean external data source that provides data ancillary to a particularmonitored transaction.

65. The system of claim 61, wherein a policy statement is operative oninformation from the additional data sources as well as informationcorresponding to transaction data items.

66. A system for determining possible lack of compliance with acompliance policy based on information stored in one or moreheterogeneous enterprise systems, comprising:

-   -   an ontology expressing the predetermined data items in an        ontology common across plural heterogeneous databases;    -   at least one computer-executable policy statement expressing a        compliance policy based on informational relationships involving        predetermined data items of electronic transactions stored in        one or more heterogeneous enterprise systems in accordance with        corresponding enterprise system schemas, the policy statement        expressed in terms of the ontology;    -   a data extractor for extracting data from the enterprise systems        identified by their corresponding enterprise system schemas;    -   a mapper for mapping the extracted data according to the        ontology to transform the data into monitoring entities;    -   a monitoring database for storing the monitoring entities; and    -   a transaction analysis engine for executing the at least one        policy statement against the monitoring entities in the        monitoring database.

67. The system of claim 66, wherein the mapper is operative for addingmetadata to form the monitoring entities.

68. The system of claim 67, wherein the metadata comprises revisioninformation that allows comparison of different versions of an entityover a period of time,

-   -   whereby the occurrence of changes over time to data in a data        source are detected and preserved, so that multiple sequential        versions of particular monitored entities are preserved.

69. The system of claim 68, wherein the metadata comprises a timestampand actor identification information.

70. The system of claim 66, wherein the transaction analysis engine isoperative for generating an exception in response to satisfaction of acondition expressed in a policy statement.

71. The system of claim 70, further comprising a display for displayinginformation relating to an exception, entities associated with theexception, and support entities associated with an exception or with anentity that triggered an exception.

72. The system of claim 70, further comprising a case management systemfor collecting information relating to one or more related exceptions asa case.

73. The system of claim 70, further comprising an exception handlingmodule for displaying information relating to one or more supportentities that are related to an entity that caused an exception.

74. The system of claim 66, wherein the extractor is initially operativefor extracting an initial selected subset of information about monitoredtransactions from the enterprise system; and thereafter responsive tochanged data in the enterprise system, extracting a second selectedsubset of information about the changed data.

75. The system of claim 66, wherein the enterprise systems include oneor more additional data sources that provide information supplemental tothe electronic transactions.

76. The system of claim 75, wherein the additional data sources includean information technology (IT) system infrastructure equipment thatprovides data corresponding to IT system utilization.

77. The system of claim 76, wherein the IT system infrastructureequipment is selected from the group: file server, application server,firewall, router, intrusion detection equipment, authentication server.

78. The system of claim 75, wherein the additional data sources includean external data source that provides data ancillary to a particularmonitored transaction.

79. The system of claim 75, wherein the policy statement is operative oninformation from the additional data sources as well as the monitoringentities.

80. A method for determining possible lack of compliance with acompliance policy based on information stored in one or moreheterogeneous enterprise systems, comprising the steps of:

-   -   determining a compliance policy based on informational        relationships involving predetermined data items of electronic        transactions stored in one or more heterogeneous enterprise        systems in accordance with corresponding enterprise system        schemas;    -   preparing an ontology to express the predetermined data items in        an ontology common across plural heterogeneous databases;    -   preparing computer-executable policy statements to express the        compliance policies in terms of the ontology;    -   extracting data from the enterprise systems identified by their        corresponding enterprise system schemas;    -   mapping the extracted data according to the ontology to        transform the data into monitoring entities;    -   storing the monitoring entities in a monitoring database; and    -   executing the policy statements against the monitoring entities        in the monitoring database.

81. The method of claim 80, further comprising the step of addingmetadata to form a monitoring entity that is stored in the monitoringdatabase.

82. The method of claim 81, wherein the metadata comprises revisioninformation that allows comparison of different versions of an entityover a period of time,

-   -   whereby the occurrence of changes over time to data in a data        source are detected and preserved, so that multiple sequential        versions of particular monitored entities are preserved.

83. The method of claim 82, wherein the metadata comprises a timestampand actor identification information.

84. The method of claim 80, further comprising the step of generating anexception in response to satisfaction of a condition expressed in apolicy statement.

85. The method of claim 84, further comprising the step of displayinginformation relating to an exception, entities associated with theexception, and support entities associated with an exception or with anentity that triggered an exception.

86. The method of claim 84, further comprising the step of collectinginformation relating to one or more related exceptions as a case.

87. The method of claim 84, further comprising the step of collectinginformation relating to one or more support entities that are related toan entity that caused an exception.

88. The method of claim 80, wherein the step of extracting comprises thesteps of:

-   -   extracting an initial selected subset of information about        monitored transactions from the enterprise system; and    -   responsive to changed data in the enterprise system, extracting        a second selected subset of information about the changed data.

89. The method of claim 80, wherein the enterprise systems include oneor more additional data sources that provide information supplemental tothe electronic transactions.

90. The method of claim 89, wherein the additional data sources includean information technology (IT) system infrastructure equipment thatprovides data corresponding to IT system utilization.

91. The method of claim 90, wherein the IT system infrastructureequipment is selected from the group: file server, application server,firewall, router, intrusion detection equipment, authentication server.

92. The method of claim 89 wherein the additional data sources includean external data source that provides data ancillary to a particularmonitored transaction.

93. The method of claim 89, wherein the policy statement is operative oninformation from the additional data sources as well as the monitoringentities.

Aspect 3 (Knowledge Base/Provide Rules, Mapping info, Extraction Info):Methods and Systems for Compliance Monitoring Knowledge Base

1. A knowledge base for use in connection with a policy compliancemonitoring system operative to determine exceptions to policiesexpressed by computer-executable policy statements, comprising:

-   -   a plurality of extractor files, the extractor files for        utilization by one or more data extractors coupled for data        communications with one or more data sources for extracting        information for utilization in policy compliance monitoring;    -   a plurality of normalizing files for access and utilization by a        mapper operative for normalizing data from the one or more data        sources against a system ontology and storing normalized data in        a monitoring database; and    -   a plurality of computer-executable compliance policy statements        for use by a transaction analysis engine, the policy statements        representing one or more predetermined policies of the        enterprise that apply to data stored in the monitoring database.

2. The knowledge base of claim 1, wherein each of plurality of extractorfiles includes information identifying a data source containinginformation for utilization in the policy compliance monitoring system,access protocols for the data source, and predetermined tables andcolumns of tables of the data source.

3. The knowledge base of claim 1, wherein an extractor file is providedfor one or more of the following types of extractors: master extractor,resync extractor, log extractor, programmatic extractor, external datasource extractor, IT environment extractor.

4. The knowledge base of claim 1, wherein the normalizing files comprisean ontology file.

5. The knowledge base of claim 4, wherein the ontology file containsinformation identifying an entity that is subject to testing for policycompliance by a compliance policy statement, in a format correspondingto expressions contained in the compliance policy statement.

6. The knowledge base of claim 4, wherein the ontology file containslinkages identifying other entities related to one of the entitiesexpressed in the ontology.

7. The knowledge base of claim 1, wherein the normalizing file includesinformation required to add metadata to data obtained from a datasource.

8. The knowledge base of claim 7, wherein the metadata comprisesrevision information that allows comparison of different versions of anentity over a period of time.

9. The knowledge base of claim 7, wherein the metadata comprises actorinformation.

10. The knowledge base of claim 1, wherein the normalizing filescomprise a mapping file.

11. The knowledge base of claim 10, wherein the mapping file identifiesspecific tables and column in a schema of a data source, andcorresponding specific tables and columns in a schema of the monitoringdatabase.

12. The knowledge base of claim 1, wherein the compliance policystatements comprise XML frames.

13. The knowledge base of claim 1, wherein the compliance policystatements comprise logical expressions for evaluating data stored inthe monitoring database against predetermined requirements, andindicators that represent the resolution of a logical expression.

14. The knowledge base of claim 13, wherein one or more indicatorscomprise an exception signaling possible lack of compliance with apolicy expressed by the compliance policy statement.

15. The knowledge base of claim 1, wherein the policy statementscomprise one or more of the following types of policy statements: ageneric policy statements, industry specific policy statements, businessprocess specific policy statements, ERP system specific policystatements, customer specific policy statements, division specificpolicy statements.

16. The knowledge base of claim 1, further comprising a user interfacefor allowing user access and modification of the extractor files, thenormalizing files, and the policy statements, for customization andconfiguration.

17. A method for maintaining a knowledge base for use in connection witha policy compliance monitoring system operative to determine exceptionsto policies expressed by computer-executable policy statements,comprising the steps of:

-   -   providing a plurality of extractor files, the extractor files        for utilization by one or more data extractors coupled for data        communications with one or more data sources for extracting        information for utilization in policy compliance monitoring;    -   providing a plurality of normalizing files for access and        utilization by a mapper operative for normalizing data from the        one or more data sources against a system ontology and storing        normalized data in a monitoring database; and    -   providing a plurality of computer-executable compliance policy        statements for use by a transactions analysis engine, the policy        statements representing one or more predetermined policies of        the enterprise that apply to the data stored in the monitoring        database.

18. The method of claim 17, wherein each of plurality of extractor filesincludes information identifying a data source containing informationfor utilization in the policy compliance monitoring system, accessprotocols for the data source, and predetermined tables and columns oftables of the data source.

19. The method of claim 17, wherein an extractor file is provided forone or more of the following types of extractors: master extractor,resync extractor, log extractor, programmatic extractor, external datasource extractor, IT environment extractor.

20. The method of claim 17, wherein the normalizing files comprise anontology file.

21. The method of claim 20, wherein the ontology file containsinformation identifying an entity that is subject to testing for policycompliance by a compliance policy statement, in a format correspondingto expressions contained in the compliance policy statement.

22. The method of claim 20, wherein the ontology file contains linkagesidentifying other entities related to one of the entities expressed inthe ontology.

23. The method of claim 17, wherein the normalizing file includesinformation required to add metadata to data obtained from a datasource.

24. The method of claim 23, wherein the metadata comprises revisioninformation that allows comparison of different versions of an entityover a period of time.

25. The method of claim 23, wherein the metadata comprises actorinformation.

26. The method of claim 17, wherein the normalizing files comprise amapping file.

27. The method of claim 26, wherein the mapping file identifies specifictables and column in a schema of a data source, and correspondingspecific tables and columns in a schema of the monitoring database.

28. The method of claim 17, wherein the compliance policy statementscomprise XML frames.

29. The method of claim 17, wherein the compliance policy statementscomprise logical expressions for evaluating data stored in themonitoring database against predetermined requirements, and indicatorsthat represent the resolution of a logical expression.

30. The method of claim 29, wherein one or more indicators comprise anexception signaling possible lack of compliance with a policy expressedby the compliance policy statement.

31. The method of claim 17, wherein the policy statements comprise oneor more of the following types of policy statements: a generic policystatements, industry specific policy statements, business processspecific policy statements, ERP system specific policy statements,customer specific policy statements, division specific policystatements.

32. The method of claim 17, further comprising the step of providing auser interface for allowing user access and modification of theextractor files, the normalizing files, and the policy statements, forcustomization and configuration.

33. A policy statement executable by a computer-based analysis engineoperative for determining a possible lack of compliance of electronictransaction data with a predetermined policy expressed by the statement,the electronic transaction data stored in a database accessed by theanalysis engine, comprising:

-   -   information identifying at least one entity in the database, the        entity comprising data items corresponding to the electronic        transaction expressed in a predetermined ontology;    -   at least one indicator comprising computer-executable logical        statements expressed in terms of the ontology that resolves to        an exception in response to a predetermined condition; and    -   information specifying a view of information resulting from        execution of the statement for provision to an external system.

34. The policy statement of claim 33, expressed as an XML datastructure.

35. The policy statement of claim 33, wherein the database is amonitoring database.

36. The policy statement of claim 33, wherein the data in the monitoringdatabase is extracted from one or more data sources.

37. The policy statement of claim 36, wherein the one or more datasources are from the group: ERP systems, enterprise application systems,external data sources, and information technology (IT) infrastructuredata.

38. The policy statement of claim 33, wherein the electronic transactiondata is obtained from one or more data sources and mapped into a schemacorresponding to the ontology and mapping information.

39. The policy statement of claim 33, wherein the at least one entity isa transactional entity.

40. The policy statement of claim 33, wherein the at least one entity isa support entity.

41. The policy statement of claim 33, wherein the at least one indicatorutilizes additional information together with entity information inresolving to an exception.

42. The policy statement of claim 33, wherein the exception is providedto an external system for user disposition.

43. The policy statement of claim 33, wherein the at least one indicatorprovides a confidence level associated with the exception.

44. The policy statement of claim 43, wherein confidence levels of aplurality of indicators are combined statistically to obtain a singlecomposite confidence level.

45. The policy statement of claim 43, wherein the predeterminedcondition is the confidence level exceeding a predetermined thresholdvalue.

46. The policy statement of claim 43, further comprising logicalstatements for computing a priority associated with an exception basedon confidence and impact.

47. The policy statement of claim 42, wherein the statement provides forcomputing a wariness associated with an entity involved in an exception,and providing wariness as an output.

48. The policy statement of claim 47, wherein wariness is computed bycombining the confidence levels of one or more exceptions asprobabilities, incrementally, as one or more exceptions are resolved,thereby providing updated values for wariness for particular entitiesover time and as a result of multiple exceptions.

49. The policy statement of claim 43, wherein the at least one indicatorprovides an expected impact expression.

50. The policy statement of claim 49, wherein the expected impactcomprises a product of the confidence level and potential impact.

51. The policy statement of claim 33, further comprising informationthat determines whether the policy statement should execute by theanalysis engine.

52. The policy statement of claim 33, further comprising informationthat identifies at least one system with which the policy statement iseffective.

53. The policy statement of claim 33, wherein the information specifyinga view of information resulting from execution of the statement forprovision to an external system comprises information relating to anentity involved in the statement.

54. The policy statement of claim 33, wherein the information specifyinga view of information resulting from execution of the statement forprovision to an external system comprises information relating to theexception.

55. A method for determining a possible lack of compliance of electronictransaction data with a predetermined policy, the electronic transactiondata stored in a database, comprising the steps of:

-   -   providing a policy statement executable by a computer-based        analysis engine operative to access the database, the policy        statement comprising:        -   information identifying at least one entity in the database,            the entity comprising data items corresponding to the            electronic transaction expressed in a predetermined            ontology;        -   at least one indicator comprising computer-executable            logical statements expressed in terms of the ontology that            resolves to an exception in response to predetermined            conditions; and        -   information specifying a view of information resulting from            execution of the statement for provision to an external            system; and    -   executing the policy statement by the analysis engine.

56. The method of claim 55, wherein the policy statement is expressed asan XML data structure.

57. The method of claim 55, wherein the database is a monitoringdatabase.

58. The method of claim 55, wherein the data in the monitoring databaseis extracted from one or more data sources.

59. The method of claim 58, wherein the one or more data sources arefrom the group: ERP systems, enterprise application systems, externaldata sources, and information technology (IT) infrastructure data.

60. The method of claim 55, wherein the electronic transaction data isobtained from one or more data sources and mapped into a schemacorresponding to the ontology and mapping information.

61. The method of claim 55, wherein the at least one entity is atransactional entity.

62. The method of claim 55, wherein the at least one entity is a supportentity.

63. The method of claim 55, wherein the at least one indicator utilizesadditional information together with entity information in resolving toan exception.

64. The method of claim 55, wherein the exception is provided to anexternal system for user disposition.

65. The method of claim 55, wherein the at least one indicator providesa confidence level associated with the exception.

66. The method of claim 65, wherein confidence levels of a plurality ofindicators are combined statistically to obtain a single compositeconfidence level.

67. The method of claim 65, wherein the predetermined condition is theconfidence level exceeding a predetermined threshold value.

68. The method of claim 65, further comprising logical statements forcomputing a priority associated with an exception based on confidenceand impact.

69. The method of claim 65, wherein the statement provides for computinga wariness associated with an entity involved in an exception, andproviding wariness as an output.

70. The method of claim 69, wherein wariness is computed by combiningthe confidence levels of one or more exceptions as probabilities,incrementally, as one or more exceptions are resolved, thereby providingupdated values for wariness for particular entities over time and as aresult of multiple exceptions.

71. The method of claim 65, wherein the at least one indicator providesan expected impact expression.

72. The method of claim 71, wherein the expected impact comprises aproduct of the confidence level and potential impact.

73. The method of claim 33, further comprising information thatdetermines whether the policy statement should execute by the analysisengine.

74. The method of claim 33, further comprising information thatidentifies at least one system with which the policy statement iseffective.

75. The method of claim 33, wherein the information specifying a view ofinformation resulting from execution of the statement for provision toan external system comprises information relating to an entity involvedin the statement.

76. The method of claim 33, wherein the information specifying a view ofinformation resulting from execution of the statement for provision toan external system comprises information relating to the exception.

Aspect 4 (CORE/Rules Execution/Frame Aspects): Methods and Systems forPolicy Statement Execution Engine

1. A system for detecting exceptions to a policy expressed in acomputer-executable policy statement, comprising:

-   -   a storage device for storing a set of policy statements, the set        of policy statements comprising at least one base policy        statement and optionally one or more custom policy statements;    -   a data retrieval subsystem for connecting to a data storage        device storing data for use in connection with determining        policy exceptions;    -   a policy analysis engine responsive to each policy statement in        the storage device for retrieving data corresponding to at least        one entity stored in the storage device that is referenced by        the policy statement    -   the policy analysis engine being further operative for        evaluating an indicator provided in the policy statement and        determining a confidence level associated with the indicator;        and    -   an exception determining component responsive to the determined        confidence level exceeding a predetermined threshold value for        generating data corresponding to an exception to the policy.

2. The system of claim 1, further comprising an output component for:

-   -   generating a description of the exception in response to an        exception; and    -   providing the exception description and confidence level value        to an external system for utilization.

3. The system of claim 1, wherein the policy analysis engine computes apotential impact of the exception in response to an exception.

4. The system of claim 1, wherein the custom policy statement comprisesa base policy statement that has been modified for particularcircumstances.

5. The system of claim 1, wherein the data corresponding to the entitystored in the storage device comprise monitoring entities stored in amonitoring database.

6. The system of claim 1, wherein the entity comprises data itemscorresponding to an electronic transaction expressed in a predeterminedontology;

-   -   wherein the indicator comprises at least one computer-executable        logical statement expressed in terms of an ontology that        resolves to the exception in response to a predetermined        condition.

7. The system of claim 1, wherein the policy statement is an XML datastructure.

8. The system of claim 1, further comprising a connection to one or moredata sources that provide additional data for use in evaluating thepolicy statement.

9. The system of claim 8, wherein the one or more data sources are fromthe group: ERP systems, enterprise application systems, external datasources, and information technology (IT) infrastructure data.

10. The system of claim 1, wherein the at least one entity is atransactional entity.

11. The system of claim 1, wherein the at least one entity is a supportentity.

12. The system of claim 1, wherein the at least one indicator utilizesadditional information together with entity information in resolving toan exception, the additional information obtained from an additionaldata source.

13. The system of claim 1, further comprising an output for providingthe exception to an external system for user disposition.

14. The system of claim 1, wherein the indicator includes a confidencelevel associated with the exception.

15. The system of claim 14, wherein confidence levels of a plurality ofindicators are combined statistically to obtain a single compositeconfidence level.

16. The system of claim 1, wherein the evaluation of the indicatorcomprises determining a predetermined condition based on retrievedinformation, and wherein the predetermined condition is a confidencelevel exceeding a predetermined threshold value.

17. The system of claim 1, further comprising an output for providinginformation relating to an entity involved in the exception to anexternal system for utilization.

18. The system of claim 1, further comprising an output for providinginformation relating to the exception to an external system forutilization.

19. A computer-implemented method for detecting exceptions to a policyexpressed in a computer-executable policy statement, comprising thesteps of:

-   -   opening a connection to a data storage device storing data for        use in connection with determining policy exceptions;    -   retrieving a base policy statement from a storage device;    -   retrieving a custom policy statement from a storage device;    -   for each policy statement, retrieving data corresponding to at        least one entity stored in the storage device that is referenced        by the policy statement;    -   evaluating an indicator provided in the policy statement;    -   determining a confidence level associated with an indicator        determined in the evaluating step; and    -   if a determined confidence level exceeds a predetermined        threshold value, generating data corresponding to an exception        to the policy.

20. The method of claim 19, further comprising the steps of:

-   -   generating a description of the exception in response to an        exception; and    -   providing the exception description and confidence level value        to an external system for utilization.

21. The method of claim 19, further comprising the step of computing apotential impact of the exception in response to an exception.

22. The method of claim 19, wherein the custom policy statementcomprises a base policy statement that has been modified for particularcircumstances.

23. The method of claim 19, wherein the data corresponding to the entitystored in the storage device comprise monitoring entities stored in amonitoring database.

24. The method of claim 19, wherein the entity comprises data itemscorresponding to an electronic transaction expressed in a predeterminedontology;

-   -   wherein the indicator comprises at least one computer-executable        logical statement expressed in terms of an ontology that        resolves to the exception in response to a predetermined        condition.

25. The method of claim 19, wherein the policy statement is an XML datastructure.

26. The method of claim 19, further comprising the step of retrievingdata from one or more data sources for use in evaluating the policystatement.

27. The method of claim 26, wherein the one or more data sources arefrom the group: ERP systems, enterprise application systems, externaldata sources, and information technology (IT) infrastructure data.

28. The method of claim 19, wherein the at least one entity is atransactional entity.

29. The method of claim 19, wherein the at least one entity is a supportentity.

30. The method of claim 19, wherein the at least one indicator utilizesadditional information together with entity information in resolving toan exception, the additional information obtained from an additionaldata source.

31. The method of claim 19, further comprising the step of providing theexception to an external system for user disposition.

32. The method of claim 19, wherein the indicator provides a confidencelevel associated with the exception.

33. The method of claim 32, wherein confidence levels of a plurality ofindicators are combined statistically to obtain a single compositeconfidence level.

34. The method of claim 19, wherein the evaluation of the indicatorcomprises determining a predetermined condition based on retrievedinformation, and wherein the predetermined condition is a confidencelevel exceeding a predetermined threshold value.

35. The method of claim 19, further comprising the step of providinginformation relating to an entity involved in the exception to anexternal system for utilization.

36. The method of claim 19, further comprising the step of providinginformation relating to the exception to an external system forutilization.

37. A computer-implemented policy statement execution system for use indetecting possible exceptions to a policy expressed in acomputer-executable policy statement, comprising:

-   -   a program module for retrieving a computer-executable policy        statement from a storage device;    -   a interpreter program module for interpreting the policy        statement and determining computer operations corresponding to        the policy statement;    -   a program module for executing computer operations determined by        the interpreter module;    -   a program module for retrieving any required data for use in        connection with the policy statement from one or more data        sources;    -   a program module for determining an exception based on        resolution of a logical expression contained in the policy        statement; and    -   an output for providing data corresponding to an exception        resulting from the exception determining program module.

38. The system of claim 37, wherein the policy statement comprises:

-   -   information identifying at least one entity in the storage        device, the entity comprising data items corresponding to an        electronic transaction expressed in a predetermined ontology;    -   at least one indicator comprising at least one        computer-executable logical statement expressed in terms of the        ontology that resolves to an exception in response to a        predetermined condition; and    -   information specifying a view of information resulting from        execution of the statement for provision to an external system.

39. The system of claim 38, wherein the policy statement is an XML datastructure and the program module for interpreting the policy statementis operative to parse an XML data structure.

40. The system of claim 38, wherein the storage device is a monitoringdatabase storing monitoring entities associated with transactions.

41. The system of claim 38, wherein the one or more data sources arefrom the group: ERP systems, enterprise application systems, externaldata sources, and information technology (IT) infrastructure data.

42. The system of claim 38, wherein the data is obtained from one ormore data sources and mapped into a schema corresponding to apredetermined ontology and mapping information, and stored in amonitoring database in an operation prior to execution of the policystatement.

43. The system of claim 38, wherein the at least one entity is atransactional entity.

44. The system of claim 38, wherein the at least one entity is a supportentity.

45. The system of claim 38, wherein the at least one indicator utilizesadditional information together with entity information in resolving toan exception.

46. The system of claim 37, wherein the exception is provided to anexternal system for user disposition.

47. The system of claim 38, wherein the at least one indicator providesa confidence level associated with the exception.

48. The system of claim 47, wherein confidence levels of a plurality ofindicators are combined statistically to obtain a single compositeconfidence level.

49. The system of claim 47, wherein the predetermined condition is theconfidence level exceeding a predetermined threshold value.

50. The system of claim 47, further comprising logical statements forcomputing a priority associated with an exception based on confidenceand impact.

51. The system of claim 47, wherein the statement provides for computinga wariness associated with an entity involved in an exception, andproviding wariness as an output.

52. The system of claim 51, wherein wariness is computed by combiningthe confidence levels of one or more exceptions as probabilities,incrementally, as one or more exceptions are resolved, thereby providingupdated values for wariness for particular entities over time and as aresult of multiple exceptions.

53. The system of claim 38, wherein the at least one indicator providesan expected impact expression.

54. The system of claim 53, wherein the expected impact comprises aproduct of the confidence level and potential impact.

55. The system of claim 37, further comprising information thatdetermines whether the policy statement should execute by the analysisengine.

56. The system of claim 37, further comprising information thatidentifies at least one system with which the policy statement iseffective.

57. The system of claim 37, wherein the information specifying a view ofinformation resulting from execution of the statement for provision toan external system comprises information relating to an entity involvedin the statement.

58. The system of claim 37, wherein the information specifying a view ofinformation resulting from execution of the statement for provision toan external system comprises information relating to the exception.

59. A method for detecting possible exceptions to a policy expressed ina computer-executable policy statement, comprising the steps of:

-   -   retrieving a computer-executable policy statement from a storage        device;    -   interpreting the policy statement to determine computer        operations corresponding to the policy statement;    -   executing computer operations determined in the interpreting        step;    -   retrieving any required data for use in connection with the        policy statement from one or more data sources;    -   determining an exception based on resolution of a logical        expression contained in the policy statement; and    -   providing a data output corresponding to an exception resulting        from the exception determining program module.

60. The method of claim 59, wherein the policy statement comprises:

-   -   information identifying at least one entity in the storage        device, the entity comprising data items corresponding to an        electronic transaction expressed in a predetermined ontology;    -   at least one indicator comprising at least one        computer-executable logical statement, expressed in terms of the        ontology, that resolves to an exception in response to a        predetermined condition; and    -   information specifying a view of information resulting from        execution of the statement for provision to an external system.

61. The method of claim 60, wherein the policy statement is an XML datastructure and step of interpreting the policy statement comprisesparsing the XML data structure.

62. The method of claim 60, wherein the storage device is a monitoringdatabase storing monitoring entities associated with transactions.

63. The method of claim 60, wherein the one or more data sources arefrom the group: ERP systems, enterprise application systems, externaldata sources, and information technology (IT) infrastructure data.

64. The method of claim 60, wherein the data is obtained from one ormore data sources and mapped into a schema corresponding to apredetermined ontology and mapping information, and stored in amonitoring database in an operation prior to execution of the policystatement.

65. The method of claim 60, wherein the at least one entity is atransactional entity.

66. The method of claim 60, wherein the at least one entity is a supportentity.

67. The method of claim 60, wherein the at least one indicator utilizesadditional information together with entity information in resolving toan exception.

68. The method of claim 59, wherein the exception is provided to anexternal system for user disposition.

69. The method of claim 60, wherein the at least one indicator providesa confidence level associated with the exception.

70. The method of claim 69, wherein confidence levels of a plurality ofindicators are combined statistically to obtain a single compositeconfidence level.

71. The method of claim 69, wherein the predetermined condition is theconfidence level exceeding a predetermined threshold value.

72. The method of claim 69, wherein the logical statements for computinga priority associated with an exception based on confidence and impact.

73. The method of claim 69, wherein the policy statement provides forcomputing a wariness associated with an entity involved in an exception,and providing wariness as an output.

74. The method of claim 73, wherein wariness is computed by combiningthe confidence levels of one or more exceptions as probabilities,incrementally, as one or more exceptions are resolved, thereby providingupdated values for wariness for particular entities over time and as aresult of multiple exceptions.

75. The method of claim 60, wherein the at least one indicator providesan expected impact expression.

76. The method of claim 75, wherein the expected impact comprises aproduct of the confidence level and potential impact.

77. The method of claim 59, wherein the information resulting fromexecution of the statement for provision to the external systemcomprises information relating to an entity involved in the statement.

78. The method of claim 59, wherein the information resulting fromexecution of the statement for provision to the external systemcomprises information relating to the exception.

Aspect 5 (Case Management): Methods and Systems for ComplianceMonitoring Case Management

1. A system for managing information of a case relating to possible lackof compliance of enterprise transactions with one or more predeterminedcompliance policies of an enterprise, comprising:

-   -   an exceptions database;    -   an input for receiving exceptions from a rules engine operative        for determining a violation of an enterprise compliance policy        based on information stored in one or more enterprise systems,        and storing the exceptions in the exceptions database;    -   a user interface control for assigning a case number to at least        one exception, the case number corresponding to a case;    -   a user interface control for assigning an owner to the        exceptions;    -   a user interface for collecting additional information relating        to a case; and    -   a display of information relating to the exception, the entities        involved in the exception, and the case to a user.

2. The system of claim 1, further comprising a user interface forreceiving user entry of notes associated with a case.

3. The system of claim 1, further comprising a user interface formaintaining a log of activities relating to a case.

4. The system of claim 1, further comprising a display of informationrelating to a priority associated with an exception assigned in a case.

5. The system of claim 1, further comprising a display of informationcorresponding to an actor associated with an exception assigned to acase.

6. The system of claim 1, further comprising a user interface controlfor assigning status information associated with the case.

7. The system of claim 6, wherein the status information is one of thegroup of detected, under review, dismissed, or fixed.

8. The system of claim 1, further comprising a display of an impactcorresponding to the exceptions involved in the case.

9. The system of claim 8, further comprising a display of the cumulativeimpact of a plurality of exceptions involved in a case.

10. The system of claim 1, further comprising a component for retrievinginformation corresponding to a plurality of transactions related toother entities associated with one or more transactions involved in thecase.

11. The system of claim 1, further comprising a display of an annotatedtimeline having a graphic indicator of one or more exceptions involvedin the case.

12. The system of claim 1, further comprising a display of an impactview for a plurality of exception involved in a case, the identities ofactors involved in the exceptions, a description of the exceptions, andan impact of the exceptions involved in the case.

13. The system of claim 1, wherein system is implemented on a computersystem independent and separate from the enterprise systems that are thesubject of case management.

14. The system of claim 1, wherein the exception information includesthe following: an exception description, a priority, informationidentifying entities involved in the exception, a confidence value,indicators associated with the exception.

15. A method for managing information of a case relating to possiblelack of compliance of enterprise transactions with one or morepredetermined compliance policies of an enterprise, comprising the stepsof:

-   -   receiving exceptions from a rules engine operative for        determining a violation of an enterprise compliance policy based        on information stored in one or more enterprise systems;    -   storing the exceptions in an exceptions database;    -   assigning a case number to at least one exception, the case        number corresponding to a case;    -   assigning an owner to the exceptions;    -   providing a user interface for collecting additional information        relating to a case; and    -   displaying information relating to the exception, the entities        involved in the exception, and the case to a user.

16. The method of claim 15, further comprising the step of providing foruser entry of notes associated with a case.

17. The method of claim 15, further comprising the step of maintaining alog of activities relating to a case.

18. The method of claim 15, further comprising the step of maintaininginformation relating to a priority associated with an exception assignedin a case.

19. The method of claim 15, further comprising the step of maintaininginformation corresponding to an actor associated with an exceptionassigned to a case.

20. The method of claim 15, further comprising the step of assigningstatus information associated with the case.

21. The method of claim 20, wherein the status information is one of thegroup of detected, under review, dismissed, or fixed.

22. The method of claim 15, further comprising the step of computing animpact corresponding to the exceptions involved in the case.

23. The method of claim 22, further comprising the step of computing thecumulative impact of a plurality of exceptions involved in a case.

24. The method of claim 15, further comprising the step of retrievinginformation corresponding to a plurality of transactions related toother entities associated with one or more transactions involved in thecase.

25. The method of claim 15, further comprising the step of displaying anannotated timeline having a graphic indicator of one or more exceptionsinvolved in the case.

26. The method of claim 15, further comprising the step of displaying animpact view for a plurality of exception, the identities of actorsinvolved in the exceptions, a description of the exceptions, and animpact of the exceptions involved in the case.

27. The method of claim 15, wherein the method is carried out on acomputer system independent and separate from the enterprise systemsthat are the subject of case management.

28. The method of claim 15, wherein the exception information includesthe following: an exception description, a priority, informationidentifying entities involved in the exception, a confidence value,indicators associated with the exception.

Aspect 6 (Linking): Methods and Systems for Entity Linking in aCompliance Policy Monitoring

1. A system for linking entities associated with electronic transactionsmonitored for compliance with predetermined compliance policies,comprising:

-   -   a monitoring database for storing data corresponding to        transactional entities that correspond to monitored transactions        and data corresponding to support entities;    -   a transactions analysis engine for executing one or more        computer-executable compliance policy statements against the        monitoring database to determine whether a transaction has        indicated an exception to a policy;    -   the transaction analysis engine, in response to detection of a        compliance policy exception based on a particular prestored        support entity, operative for retrieving information        corresponding to the particular prestored support entity; and    -   a component for retrieving information corresponding to other        support entities that are related to the particular prestored        support entity.

2. The system of claim 1, wherein the support entities comprise priortransactional entities.

3. The system of claim 1, further comprising a display of informationcorresponding to the particular prestored entity in a user interface, inproximity to information corresponding to the other support entitiesrelated to the particular prestored support entity.

4. The system of claim 1, wherein a transactional entity comprises acomputer-based financial transaction generated by an enterprisefinancial system.

5. The system of claim 4, wherein the financial transaction comprises avoucher, purchase order, or payment.

6. The system of claim 4, wherein the transactional entity is a voucher,the prestored support entity is a previous voucher in the enterprisefinancial system, the policy statement reflects a policy that duplicatevouchers are to be indicated as an exception, and the other relatedsupport entity is a purchase order connected to the transactionalvoucher that triggered the exception.

7. The system of claim 1, wherein the support entities comprise entitiesassociated with an enterprise computer application.

8. The system of claim 7, wherein the support entities comprise datarecords of employees, vendors, customers, and contractors.

9. The system of claim 1, wherein the monitoring database includes datafrom disparate data sources.

10. The system of claim 9, wherein the retrieved informationcorresponding to the particular prestored support entity comprisesinformation obtained from disparate data sources.

11. The system of claim 1, wherein the information corresponding toother support entities that are related to the particular prestoredsupport entity is connected to the particular prestored support entityby an enterprise ontology.

12. In a system for monitoring electronic transactions for compliancewith predetermined compliance policies, a method for linking entitiesassociated with the transactions, comprising the steps of:

-   -   storing data corresponding to transactional entities in a        monitoring database, the transactional entities corresponding to        monitored transactions;    -   storing data corresponding to support entities in the monitoring        database;    -   executing one or more computer-executable compliance policy        statements against the monitoring database to determine whether        a transaction has indicated an exception to a policy;    -   in response to detection of a compliance policy exception based        on a particular prestored support entity, retrieving information        corresponding to the particular prestored support entity; and    -   retrieving information corresponding to other support entities        that are related to the particular prestored support entity.

13. The method of claim 12, wherein the support entities comprise priortransactional entities.

14. The method of claim 12, further comprising the step of displayinginformation corresponding to the particular prestored entity in a userinterface, and displaying information corresponding to the other supportentities related to the particular prestored support entity.

15. The method of claim 12, wherein the transactional entity comprises acomputer-based financial transaction generated by an enterprisefinancial system.

16. The method of claim 15, wherein the financial transaction comprisesa voucher, purchase order, or payment.

17. The method of claim 15, wherein the transactional entity is avoucher, the prestored support entity is a previous voucher in theenterprise financial system, the policy statement reflects a policy thatduplicate vouchers are to be indicated as an exception, and the otherrelated support entity is a purchase order connected to thetransactional voucher that triggered the exception.

18. The method of claim 12, wherein the support entities compriseentities associated with an enterprise computer application.

19. The method of claim 18, wherein the support entities comprise datarecords of employees, vendors, customers, and contractors.

20. The method of claim 12, wherein the monitoring database includesdata from disparate data sources.

21. The method of claim 20, wherein the retrieved informationcorresponding to the particular prestored support entity comprisesinformation obtained from disparate data sources.

22. The method of claim 12, wherein the information corresponding toother support entities that are related to the particular prestoredsupport entity is connected to the particular prestored support entityby an enterprise ontology.

23. A system for user handling of related entities associated withelectronic transactions monitored for compliance with predeterminedcompliance policies, comprising:

-   -   an exceptions data store for storing data corresponding to        exceptions resulting from the execution of one or more        computer-executable compliance policy statements against stored        electronic transactions data;    -   a display of a plurality of exceptions that occurred as result        of policy statement execution;    -   a user input for user selection of one of the plurality of        exceptions,    -   a display of detailed information about a selected exception;    -   a display of information corresponding to one or more entities        associated with the exception; and    -   a user input for a user command with respect to a particular        entity in the display of information corresponding to one or        more entities;    -   a display of information corresponding to related entities        associated with the particular entity.

24. The system of claim 23, wherein the transactions data is stored in amonitoring database.

25. The system of claim 23, wherein the detailed information about theselected exception comprises a description of the exception.

26. The system of claim 25, wherein the description of the exceptionincludes information identifying at least one indicator associated withthe computer-executable policy statement.

27. The system of claim 26, wherein the indicator includes informationrelating to other exceptions generated as the result of execution ofother computer-executable policy statements.

28. The system of claim 23, wherein the display of informationcorresponding to one or more entities associated with the exceptioncomprises a display of information relating to support entitiesassociated with the transaction.

29. The system of claim 28, wherein the support entities comprise priortransactional entities.

30. The system of claim 28, wherein the support entities compriseentities associated with an enterprise computer application.

31. The system of claim 23, wherein the display of informationcorresponding to related entities associated with the particular entitycomprises a display of detailed information about related entities in aseparate display region on a user interface, in conjunction withinformation describing the exception corresponding to the particularentity and the related entities.

32. The system of claim 23, wherein the stored electronic transactionsdata is stored in a monitoring database separately from the datacorresponding to the electronic transactions, and wherein the datacorresponding to the electronic transactions is mapped into anenterprise ontology that corresponds to the expressions of thecomputer-executable policy statements.

33. The system of claim 32, wherein the monitoring database includesdata from disparate data sources.

34. The system of claim 33, wherein the display of informationcorresponding to the entities associated with the exception and therelated entities comprises information obtained from disparate datasources.

35. In a system for monitoring electronic transactions for compliancewith predetermined compliance policies, a method for user handling ofrelated entities associated with the transactions, comprising the stepsof:

-   -   storing data corresponding to exceptions resulting from the        execution of one or more computer-executable compliance policy        statements against stored electronic transactions data;    -   displaying a list of a plurality of exceptions that occurred as        result of policy statement execution;    -   in response to user selection of one of the plurality of        exceptions, displaying detailed information about the selected        exception;    -   displaying information corresponding to one or more entities        associated with the exception; and    -   in response to a user command with respect to a particular        entity in the information displayed about one or more entities,        displaying information corresponding to related entities        associated with the particular entity.

36. The method of claim 35, wherein the transactions data is stored in amonitoring database.

37. The method of claim 35, wherein the detailed information about theselected exception comprises a description of the exception.

38. The method of claim 37, wherein the description of the exceptionincludes information identifying at least one indicator associated withthe computer-executable policy statement.

39. The method of claim 38, wherein the indicator includes informationrelating to other exceptions generated as the result of execution ofother computer-executable policy statements.

40. The method of claim 35, wherein the step of displaying informationcorresponding to one or more entities associated with the exceptioncomprises displaying information relating to support entities associatedwith the transaction.

41. The method of claim 40, wherein the support entities comprise priortransactional entities.

42. The method of claim 40, wherein the support entities compriseentities associated with an enterprise computer application.

43. The method of claim 35, wherein the step of displaying informationcorresponding to related entities associated with the particular entitycomprises displaying detailed information about related entities in aseparate display region on a user interface, in conjunction withinformation describing the exception corresponding to the particularentity and the related entities.

44. The method of claim 35, wherein the stored electronic transactionsdata is stored in a monitoring database separately from the datacorresponding to the electronic transactions, and wherein the datacorresponding to the electronic transactions is mapped into anenterprise ontology that corresponds to the expressions of thecomputer-executable policy statements.

45. The method of claim 44, wherein the monitoring database includesdata from disparate data sources.

46. The method of claim 45, wherein the display of informationcorresponding to the entities associated with the exception and therelated entities comprises information obtained from disparate datasources.

Aspect 7 (Versions): Methods and Systems for Monitoring TransactionEntity Versions for Policy Compliance

1. A system for determining lack of compliance of a transactional entitywith one or more predetermined policies by maintaining an historicalrecord of the transactional entity as changes are made to the entity,comprising:

-   -   a master data extractor for establishing an initial instance of        a transactional entity in a monitoring database by extracting a        first selected subset of information relating to the        transactional entity from a host data source storing data        associated with the transactional entity;    -   a monitoring database for storing the first subset of        information and version information in a monitoring database as        a monitoring entity;    -   a changed data extractor responsive to changed data associated        with the transactional entity, for establishing a subsequent        instance of the transactional entity in the monitoring database        by extracting a second selected subset of information relating        to the transactional entity from the host data source and        storing the second subset of information and version information        in the monitoring database as a second monitoring entity;    -   a transaction analysis engine for applying predetermined policy        rules to the monitoring entities in the monitoring database to        determine lack of compliance of the initial and subsequent        instances of the transactional entity with one or more        predetermined policies that make reference to different versions        of a particular transactional entity.

2. The system of claim 1, further comprising a component for addingmetadata to the subsets of information prior to storage in themonitoring database as monitoring entities.

3. The system of claim 2, wherein the metadata includes the versioninformation.

4. The system of claim 2, wherein the metadata comprises a transactionalentity identifier, actor identification information, and a timestamp.

5. The system of claim 1, further comprising a mapper for normalizingthe selected subset of information into an enterprise ontology bymapping the selected subset of information into predeterminedcorresponding normalized data fields of the monitoring database.

6. The system of claim 1, wherein the data sources comprise anenterprise system.

7. The system of claim 1, wherein the predetermined policy rules areexpressed in computer-executable policy statements.

8. The system of claim 1, wherein the transactional entity comprisesdata items corresponding to an electronic transaction expressed in apredetermined ontology;

-   -   wherein the policy statement comprises at least one indicator        comprising at least one computer-executable logical statement        expressed in terms of the ontology that resolves to an exception        in response to a predetermined condition; and    -   further comprising means for outputting information        corresponding to the exception.

9. The system of claim 1, wherein the first and second selected subsetsof data are obtained from the host data source by a data extractor.

10. The system of claim 9, wherein the first selected subset of data isobtained by a master extractor.

11. The system of claim 9, wherein the second selected subset of data isobtained by one or more of the group: programmatic extractor, logextractor, resync extractor.

12. A computer-implemented method for determining lack of compliance ofa transactional entity with one or more predetermined policies bymaintaining an historical record of the transactional entity as changesare made to the entity, comprising the steps of:

-   -   establishing an initial instance of a transactional entity in a        monitoring database by extracting a first selected subset of        information relating to the transactional entity from a host        data source storing data associated with the transactional        entity;    -   storing the subset of information and version information in a        monitoring database as a monitoring entity;    -   in response to a determination of a change to data associated        with the transactional entity, establishing a subsequent        instance of the transactional entity in the monitoring database        by extracting a second selected subset of information relating        to the transactional entity from the host data source;    -   storing the second subset of information and version information        in the monitoring database as a second monitoring entity;    -   applying predetermined policy rules to the monitoring entities        in the monitoring database to determine lack of compliance of        the initial and subsequent instances of the transactional entity        with one or more predetermined policies that make reference to        different versions of a particular transactional entity.

13. The method of claim 12, further comprising the step of:

-   -   adding metadata to the subsets of information prior to storage        in the monitoring database as monitoring entities.

14. The method of claim 13, wherein the metadata includes the versioninformation.

15. The method of claim 13, wherein the metadata comprises atransactional entity identifier, actor identification information, and atimestamp.

16. The method of claim 12, further comprising the step of normalizingthe selected subset of information into an enterprise ontology bymapping the selected subset of information into predeterminedcorresponding normalized data fields of the monitoring database.

17. The method of claim 12, wherein the data sources comprise anenterprise system.

18. The method of claim 12, wherein the predetermined policy rules areexpressed in computer-executable policy statements.

19. The method of claim 12, wherein the transactional entity comprisesdata items corresponding to an electronic transaction expressed in apredetermined ontology;

-   -   wherein the policy statement comprises at least one indicator        comprising at least one computer-executable logical statement        expressed in terms of the ontology that resolves to an exception        in response to a predetermined condition; and    -   further comprising the step of providing information        corresponding to the exception as an output.

20. The method of claim 12, wherein the first and second selectedsubsets of data are obtained from the host data source by a dataextractor.

21. The method of claim 20, wherein the first selected subset of data isobtained by a master extractor.

22. The method of claim 20, wherein the second selected subset of datais obtained by one or more of the group: programmatic extractor, logextractor, resync extractor.

The described embodiments were chosen and described in order to explainthe principles of the invention and their practical application so as toenable those skilled in the art to make and use the invention andvarious embodiments and with various modifications as are suited to theparticular use contemplated. Alternative embodiments will becomeapparent to those skilled in the art to which the present inventionpertains without departing from its spirit and scope. Accordingly, thescope of the present invention is defined by the appended claims ratherthan the foregoing description and the exemplary embodiments describedtherein.

1. A system for monitoring transactions of an enterprise stored in oneor more enterprise applications associated with the enterprise todetermine possible lack of compliance of a particular transaction withone or more predetermined compliance policies of the enterprise,comprising: a data extractor coupled for data communications with one ormore enterprise systems for extracting a selected subset of informationabout a monitored transaction and storing the selected subset ofinformation in a monitoring database; a transaction analysis engine forexecuting one or more computer-executable compliance policy statementsagainst the monitoring database; and a reporting component for providingan output corresponding to an exception indicating a possible lack ofcompliance with a policy reflected by the one or more compliance policystatements.
 2. The system of claim 1, wherein the reporting componentcomprises a user interface operative for displaying information relatingto exceptions, entities associated with exceptions, and support entitiesassociated with either exceptions or with an entity that triggered anexception.
 3. The system of claim 1, further comprising a normalizingcomponent for normalizing the selected subset of information from theenterprise system against a monitoring ontology and storing normalizeddata corresponding to the selected subset of information in themonitoring database.
 4. The system of claim 3, further comprising aknowledge base for storing the policy statements, extraction informationutilized by the data extractor, a monitoring ontology, and mappinginformation.
 5. The system of claim 1, further comprising a stagingdatabase for caching information received from an enterprise databaseprior to storage in the monitoring database.
 6. The system of claim 1,further comprising a component for adding metadata to the selectedsubset of information about a monitored transaction from the enterprisedatabase to form a monitoring entity that is stored in the monitoringdatabase.
 7. The system of claim 6, wherein the metadata comprisesrevision information that allows comparison of different versions of anentity over a period of time, whereby the occurrence of changes overtime to data in the enterprise database are detected and preserved, sothat multiple sequential versions of particular monitored entities arepreserved.
 8. The system of claim 6, wherein the metadata comprises atimestamp and actor identification information.
 9. The system of claim1, further comprising an exceptions store for storing a plurality ofexceptions.
 10. The system of claim 1, further comprising a casemanagement system for storing a plurality of related exceptions, andproviding a management and reporting function based on information fromthe plurality of related exceptions.
 11. The system of claim 1, whereinthe enterprise systems comprise a plurality of heterogeneous databasesthat store information relating to business transactions of theenterprise, in which one or more predetermined data fields in a firstone of the heterogeneous databases contains information relating to oneor more predetermined data fields in a second one of the heterogeneousdatabases, and further comprising a mapper operative to normalizeinformation from disparate databases via by a common ontology so as toprovide for monitoring of business transactions that transcend thetransactions stored in a single one of the enterprise's databases. 12.The system of claim 1, wherein the enterprise systems include one ormore additional data sources that provide information supplemental tothe monitored transactions.
 13. The system of claim 12, wherein theadditional data sources include an information technology (IT) systeminfrastructure equipment that provides data corresponding to IT systemutilization.
 14. The system of claim 13, wherein the IT systeminfrastructure equipment is selected from the group: file server,application server, firewall, router, intrusion detection equipment,authentication server.
 15. The system of claim 12 wherein the additionaldata sources include an external data source that provides dataancillary to a particular monitored transaction.
 16. The system of claim12, wherein a policy statement is operative on information from theadditional data sources as well as information corresponding to themonitored transaction.
 17. A method for monitoring transactions of anenterprise stored in one or more enterprise applications associated withthe enterprise to determine possible lack of compliance of a particulartransaction with one or more predetermined compliance policies of theenterprise, comprising the steps of: extracting a selected subset ofinformation about a monitored transaction from one or more enterprisesystems; storing the selected subset of information in a monitoringdatabase; executing one or more computer-executable compliance policystatements against the monitoring database; and providing an outputcorresponding to an exception indicating a possible lack of compliancewith a policy reflected by the one or more compliance policy statements.18. The method of claim 1, wherein the output is provided via a userinterface operative for displaying information relating to exceptions,entities associated with exceptions, and support entities associatedwith either exceptions or with an entity that triggered an exception.19. The method of claim 1, further comprising the steps of normalizingthe selected subset of information from the enterprise system against amonitoring ontology and storing normalized data corresponding to theselected subset of information in the monitoring database.
 20. Themethod of claim 3, further comprising the step of storing the policystatements, extraction information utilized in the extracting step, amonitoring ontology, and mapping information in a knowledge base. 21.The method of claim 1, further comprising the step of cachinginformation received from an enterprise database in a staging databaseprior to storage in the monitoring database.
 22. The method of claim 1,further comprising the step of adding metadata to the selected subset ofinformation about a monitored transaction from the enterprise databaseto form a monitoring entity that is stored in the monitoring database.23. The method of claim 6, wherein the metadata comprises revisioninformation that allows comparison of different versions of an entityover a period of time, whereby the occurrence of changes over time todata in the enterprise database are detected and preserved, so thatmultiple sequential versions of particular monitored entities arepreserved.
 24. The method of claim 6, wherein the metadata comprises atimestamp and actor identification information.
 25. The system of claim1, further comprising the step of storing a plurality of exceptions inan exceptions store.
 26. The system of claim 1, further comprising thesteps of storing a plurality of related exceptions in connection with acase management system, and providing a management and reportingfunction based on information from the plurality of related exceptions.27. The method of claim 1, wherein the enterprise systems comprise aplurality of heterogeneous databases that store information relating tobusiness transactions of the enterprise, in which one or morepredetermined data fields in a first one of the heterogeneous databasescontains information relating to one or more predetermined data fieldsin a second one of the heterogeneous databases, and further comprisingthe step of normalizing information from the heterogeneous databases viaby a common ontology so as to provide for monitoring of businesstransactions that transcend the transactions stored in a single one ofthe enterprise's databases.
 28. The method of claim 17, wherein theenterprise systems include one or more additional data sources thatprovide information supplemental to the monitored transactions.
 29. Themethod of claim 28, wherein the additional data sources include aninformation technology (IT) system infrastructure equipment thatprovides data corresponding to IT system utilization.
 30. The method ofclaim 29, wherein the IT system infrastructure equipment is selectedfrom the group: file server, application server, firewall, router,intrusion detection equipment, authentication server.
 31. The method ofclaim 28 wherein the additional data sources include an external datasource that provides data ancillary to a particular monitoredtransaction.
 32. The method of claim 28, wherein a policy statement isoperative on information from the additional data sources as well asinformation corresponding to the monitored transaction.
 33. A system formonitoring transactions of an enterprise stored in one or moreenterprise systems associated with the enterprise to determine possiblelack of compliance of a particular transaction with one or morepredetermined compliance policies of the enterprise, comprising: a dataextractor for extracting a selected subset of information about amonitored transaction from an enterprise system; a mapper fornormalizing data corresponding to the selected subset of information ina monitoring database; a transaction analysis engine for executing oneor more computer-executable compliance policy statements against thedata stored in the monitoring database and determining an exception; anda reporting component for providing an output corresponding to theexception as indicating a possible lack of compliance with a policyreflected by the one or more compliance policy statements.
 34. Thesystem of claim 33, wherein the data extractor is operative to effect aninitial master extraction to obtain an initial selected subset ofinformation corresponding to one or more monitored transactions, andthereafter operative to extract changed information.
 35. The system ofclaim 34, wherein the data extractor comprises one or more of thefollowing: a programmatic extractor, a log extractor, a resyncextractor, and an external data source extractor.
 36. The system ofclaim 33, wherein the extractor obtains data from disparate datasources.
 37. The system of claim 33, wherein the enterprise systemscomprise a plurality of heterogeneous databases that store informationrelating to business transactions of the enterprise, in which one ormore predetermined data fields in a first one of the heterogeneousdatabases contains information relating to one or more predetermineddata fields in a second one of the heterogeneous databases, and whereinthe mapper is operative to normalize information from the heterogeneousdatabases via by a common ontology so as to provide for monitoring ofbusiness transactions that transcend the transactions stored in a singleone of the enterprise's databases.
 38. The system of claim 33, whereinthe enterprise systems include one or more additional data sources thatprovide information supplemental to the monitored transactions.
 39. Thesystem of claim 38, wherein the additional data sources include aninformation technology (IT) system infrastructure equipment thatprovides data corresponding to IT system utilization.
 40. The system ofclaim 39, wherein the IT system infrastructure equipment is selectedfrom the group: file server, application server, firewall, router,intrusion detection equipment, authentication server.
 41. The system ofclaim 38, wherein the additional data sources include an external datasource that provides data ancillary to a particular monitoredtransaction.
 42. The system of claim 38, wherein a policy statement isoperative on information from the additional data sources as well asinformation corresponding to a monitored transaction.
 43. A method formonitoring transactions of an enterprise stored in one or moreenterprise systems associated with the enterprise to determine possiblelack of compliance of a particular transaction with one or morepredetermined compliance policies of the enterprise, comprising thesteps of: extracting a selected subset of information about a monitoredtransaction from an enterprise system; normalizing data corresponding tothe selected subset of information in a monitoring database; executingone or more computer-executable compliance policy statements against thedata stored in the monitoring database and determining an exception; andproviding an output corresponding to the exception as indicating apossible lack of compliance with a policy reflected by the one or morecompliance policy statements.
 44. The method of claim 43, whereinextracting step comprises an initial master extraction to obtain aninitial selected subset of information corresponding to one or moremonitored transactions, and thereafter extracting changed information.45. The method of claim 44, wherein extracting step is effected by oneor more of the following computer software components: a programmaticextractor, a log extractor, a resync extractor, and an external datasource extractor.
 46. The method of claim 43, wherein step of extractingcomprises obtaining data from disparate data sources.
 47. The method ofclaim 43, wherein the enterprise systems comprise a plurality ofheterogeneous databases that store information relating to businesstransactions of the enterprise, in which one or more predetermined datafields in a first one of the heterogeneous databases containsinformation relating to one or more predetermined data fields in asecond one of the heterogeneous databases, and wherein the step ofnormalizing comprises mapping information from the heterogeneousdatabases via by a common ontology into a schema of the monitoringdatabase so as to provide for monitoring of business transactions thattranscend the transactions stored in a single one of the enterprise'sdatabases.
 48. The method of claim 43, wherein the enterprise systemsinclude one or more additional data sources that provide informationsupplemental to the monitored transactions.
 49. The method of claim 48,wherein the additional data sources include an information technology(IT) system infrastructure equipment that provides data corresponding toIT system utilization.
 50. The method of claim 49, wherein the IT systeminfrastructure equipment is selected from the group: file server,application server, firewall, router, intrusion detection equipment,authentication server.
 51. The method of claim 48 wherein the additionaldata sources include an external data source that provides dataancillary to a particular monitored transaction.
 52. The method of claim48, wherein a policy statement is operative on information from theadditional data sources as well as information corresponding to themonitored transaction.
 53. A system operative for monitoringtransactions of an enterprise stored in one or more enterprise systems,the transactions corresponding to one or more business transactions ofthe enterprise, and indicating possible lack of compliance of a businesstransaction with one or more predetermined policies of the enterprise,comprising: a communications interface for coupling to the one or moreenterprise databases for receiving data; an extractor for extracting aselected subset of information about monitored transactions from anenterprise system via the communication interface, the selected subsetof information corresponding to a predetermined selection of data fieldsfrom a predetermined selection of database tables storing businesstransactions; an enterprise ontology store; a mapper for normalizing theselected subset of information in accordance with the enterpriseontology by mapping the extracted selected subset of information intopredetermined corresponding normalized data fields of a monitoringdatabase; a monitoring database for storing the normalized subset ofinformation as a monitoring entity; a knowledge base for storing one ormore computer-executable policy statements, the policy statementsrepresenting one or more predetermined policies of the enterprise thatapply to the data of monitoring entities; a transaction analysis enginefor executing one or more of the policy statements from the knowledgebase against the monitoring entities in the monitoring database; and anexceptions store operative in response to the determination from theexecution of a policy statement of an exception to a predeterminedpolicy, for storing information corresponding to the exceptionindicating a possible lack of compliance with the predetermined policy.54. The system of claim 53, further comprising an informational displayfor displaying information identifying monitoring entities thatcorrespond to the exception.
 55. The system of claim 53, wherein themapper is operative to associate version information with eachmonitoring entity, whereby the occurrence of changes over time to datain the enterprise database are detected and preserved, so that multiplesequential versions of particular monitored entities are preserved. 56.The system of claim 53, wherein a policy statement contains anexpression of a sequential relationship between a plurality of businesstransactions, whereby the occurrence of a second type of businesstransaction occurring before a first type of business transactioncorresponds to an exception.
 57. The system of claim 56, wherein thefirst type of business transaction is a purchase order, and the secondtype of business transaction is a payment.
 58. The system of claim 53,wherein the enterprise system includes a component operative foreffecting predetermined enterprise system policies that are specific tothe particular enterprise, and wherein the predetermined policieseffected by the computer-executable policy statements are operative todetect circumvention of the predetermined enterprise system policies.59. The system of claim 58, wherein the policy statements relate to abusiness activity sequence that can be overridden by an enterprisesystem user in circumventions of an enterprise system policy, wherebyuser overriding of policies in the enterprise database are detected. 60.The system of claim 53, wherein the enterprise systems comprise aplurality of heterogeneous databases that store information relating tobusiness transactions of the enterprise, in which one or morepredetermined data fields in a first one of the heterogeneous databasescontains information relating to one or more predetermined data fieldsin a second one of the heterogeneous databases, whereby information fromdisparate databases is normalized by the ontology so as to provide formonitoring of business transactions that transcend the transactionsstored in a single one of the enterprise's databases.
 61. The system ofclaim 60, wherein the first heterogeneous database is an ERP databasethat includes one or more data fields corresponding to bank accountinformation, and wherein the second heterogeneous database is an HRdatabase that includes one or more data fields corresponding to a bankaccount information, and wherein the policy statement includes logicoperative to compare bank account information associated with selectedtransactions in the ERP database with bank account informationassociated with selected transactions in the HR database.
 62. The systemof claim 61, wherein bank account information in the ERP database is avendor's bank account number, the bank account information in the HRdatabase is employee bank account number, and the policy statement isoperative to determine whether there is a correspondence between a bankaccount of a vendor and a bank account of an employee.
 63. The system ofclaim 53, wherein mapper is operative for storing the data of theselected subset associated with a data field identifier from theenterprise ontology, so that the extracted data is identified inaccordance with the enterprise ontology.
 64. The system of claim 53,wherein the mapper is further operative for adding metadata to thenormalized subsets of information prior to storage in the monitoringdatabase as monitoring entities.
 65. The system of claim 64, wherein themetadata is selected from the group: version information, atransactional entity identifier, actor identification information, and atimestamp.
 66. The system of claim 53, further comprising an exceptionsmanagement system for collecting information relating to a plurality ofexceptions.
 67. The system of claim 66, wherein the exceptionsmanagement system is associated with a case management system thatstores information relating to a plurality of related exceptions. 68.The system of claim 53, wherein the exceptions management system isoperative for storing status information in association with anexception indicating a status of processing of the exception.
 69. Thesystem of 68, wherein the status information is one of the groupcomprising detected, under review, dismissed, and fixed.
 70. The systemof claim 53, further comprising a component operative for linking aplurality of transactions by retrieving additional informationcorresponding to other transactions based on predetermined informationobtained from one or more exceptions.
 71. The system of claim 53,further comprising a program module operative for determiningrelationships between entities as a function of associations betweenentities and transactions.
 72. The system of claim 53, furthercomprising a temporary staging database coupled between the extractorand the mapper, and wherein the mapper is operative on data stored inthe staging database for its mapping operations, whereby computationallyintensive tasks of identifying changed entities and normalizing can beperformed without adverse impact on the source enterprise system. 73.The system of claim 53, wherein the extractor is responsive to dataprovided by a programmatic interface with an enterprise database thatprovides no direct query capability.
 74. The system of claim 53, whereinthe extractor is responsive to data provided in a log file from anenterprise database.
 75. The system of claim 53, wherein the enterprisesystems include one or more additional data sources that provideinformation supplemental to the monitored transactions.
 76. The systemof claim 75, wherein the additional data sources include an informationtechnology (IT) system infrastructure equipment that provides datacorresponding to IT system utilization.
 77. The system of claim 76,wherein the IT system infrastructure equipment is selected from thegroup: file server, application server, firewall, router, intrusiondetection equipment, authentication server.
 78. The system of claim 76wherein the additional data sources include an external data source thatprovides data ancillary to a particular monitored transaction.
 79. Thesystem of claim 75, wherein a policy statement is operative oninformation from the additional data sources as well as informationcorresponding to monitored entities.
 80. A computer-implemented methodfor monitoring transactions of an enterprise stored in one or moreenterprise systems associated with an enterprise, the transactionscorresponding to one or more business transactions of the enterprise, todetermine possible lack of compliance of a particular businesstransaction with one or more predetermined policies of the enterprise,comprising the steps of: extracting a selected subset of informationabout monitored transactions from an enterprise system, the selectedsubset of information corresponding to a predetermined selection of datafields from a predetermined selection of database tables storingbusiness transactions; normalizing the selected subset of informationinto an enterprise ontology by mapping the extracted selected subset ofinformation into predetermined corresponding normalized data fields of amonitoring database; storing the normalized subset of information in themonitoring database as a monitoring entity; storing one or morecomputer-executable policy statements in a knowledge base, the policystatements representing one or more predetermined policies of theenterprise that apply to the data of monitoring entities; executing oneor more policy statements from the knowledge base against the monitoringentities in the monitoring database; and in response to thedetermination from the execution of a policy statement of an exceptionto a predetermined policy, providing an output corresponding to anexception indicating a possible lack of compliance with thepredetermined policy.
 81. The method of claim 80, further comprising thestep of displaying information identifying the monitoring entities thatcorrespond to the exception.
 82. The method of claim 80, furthercomprising the step of associating version information with themonitoring entities so as to facilitate comparison of different versionsof the same entity over time, whereby the occurrence of changes overtime to data in the enterprise database are detected and preserved, sothat multiple sequential versions of particular monitored entities arepreserved.
 83. The method of claim 80, further comprising the steps of:associating a timestamp with each monitoring entity; storing thetimestamp in the monitoring database in association with the monitoringentity; and preserving a temporal record of a plurality of timestampedmonitoring entities relating to a particular set of information in themonitored database.
 84. The method of claim 80, wherein a policystatement stores an expression of a sequential relationship between aplurality of business transactions, whereby the occurrence of a secondtype of business transaction occurring before a first type of businesstransaction corresponds to an exception.
 85. The method of claim 84,wherein the first type of business transaction is a purchase order, andthe second type of business transaction is a payment.
 86. The method ofclaim 80, wherein the enterprise system includes a component operativefor effecting predetermined enterprise system policies that are specificto the particular enterprise, and wherein the predetermined policieseffected by the computer-executable policy statements are operative todetect circumvention of the predetermined enterprise system policies.87. The method of claim 86, wherein the policy statements relate to abusiness activity sequence that can be overridden by an enterprisesystem user in circumvention of an enterprise system policy, whereby themethod can be employed to monitor the overriding of policies in theenterprise database.
 88. The method of claim 80, wherein the enterprisesystems comprise a plurality of heterogeneous databases that storeinformation relating to business transactions of the enterprise, inwhich one or more predetermined data fields in a first one of theheterogeneous databases contains information relating to one or morepredetermined data fields in a second one of the heterogeneousdatabases, whereby information from disparate databases is normalized bya common ontology so as to provide for monitoring of businesstransactions that transcend the transactions stored in a single one ofthe enterprise's databases.
 89. The method of claim 88, wherein thefirst heterogeneous database is an ERP database that includes one ormore data fields corresponding to bank account information, and whereinthe second heterogeneous database is an HR database that includes one ormore data fields corresponding to a bank account information, andwherein the policy statement includes logic operative to compare bankaccount information associated with selected transactions in the ERPdatabase with bank account information associated with selectedtransactions in the HR database.
 90. The method of claim 89, whereinbank account information in the ERP database is a vendor's bank accountnumber, the bank account information in the HR database is employee bankaccount number, and the policy statement is operative to determinewhether there is a correspondence between a bank account of a vendor anda bank account of an employee.
 91. The method of claim 80, wherein thestep of normalizing the data includes the step of storing the data ofthe selected set associated with a data field identifier from theontology, so that the extracted data is identified in accordance withthe enterprise ontology.
 92. The method of claim 80, further comprisingthe step of adding metadata to the normalized subsets of informationprior to storage in the monitoring database as monitoring entities. 93.The method of claim 92, wherein the metadata is selected from the group:version information, a transactional entity identifier, actoridentification information, and a timestamp.
 94. The method of claim 80,further comprising the step of collecting information relating to one ormore related exceptions as a case.
 95. The method of claim 80, furthercomprising the step of collecting information relating to one or moresupport entities that are related to an entity that caused an exception.96. The method of claim 80, further comprising the step of storingstatus information in association with an exception indicating a statusof processing of the exception.
 97. The method of 96, wherein the statusinformation is one of the group comprising detected, under review,dismissed, and fixed.
 98. The method of claim 80, further comprising thestep of linking a plurality of transactions by retrieving additionalinformation corresponding to other transactions based on predeterminedinformation obtained from one or more exceptions.
 99. The method ofclaim 80, further comprising the step of determining relationshipsbetween entities as a function of associations between entities andtransactions.
 100. The method of claim 80, further comprising the stepof extracting the selected subset of information about monitoredtransactions to a temporary staging database, whereby computationallyintensive tasks of identifying changed entities and normalizing can beperformed without adverse impact on the source enterprise system. 101.The method of claim 80, wherein the step of extracting comprisesreceiving information provided by a programmatic interface with anenterprise system that provides no direct query capability to itsdatabase.
 101. The method of claim 80, wherein the step of extractingcomprises receiving information provided in a log file from anenterprise system that contains the entire new entity or providessufficient information for a query to obtain new data items only. 103.The method of claim 80, wherein the step of extracting comprisesreceiving information in response to queries from an enterprise systemfor an initial set of entities, and further comprising the step ofdetermining from data in a staging database what information has changedsince a master extraction.
 104. The method of claim 80, wherein theenterprise systems include one or more additional data sources thatprovide information supplemental to the monitored transactions.
 105. Themethod of claim 104, wherein the additional data sources include aninformation technology (IT) system infrastructure equipment thatprovides data corresponding to IT system utilization.
 106. The method ofclaim 105, wherein the IT system infrastructure equipment is selectedfrom the group: file server, application server, firewall, router,intrusion detection equipment, authentication server.
 107. The method ofclaim 104 wherein the additional data sources include an external datasource that provides data ancillary to a particular monitoredtransaction.
 108. The method of claim 104, wherein a policy statement isoperative on information from the additional data sources as well asinformation corresponding to monitored transactions.